From Michael.Jones@microsoft.com Tue Jan 17 00:50: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 CA74821F860F for ; Tue, 17 Jan 2012 00:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.038 X-Spam-Level: X-Spam-Status: No, score=-5.038 tagged_above=-999 required=5 tests=[AWL=1.560, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5Oaa9j-euDE for ; Tue, 17 Jan 2012 00:50:42 -0800 (PST) Received: from TX2EHSOBE001.bigfish.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3B01B21F85E5 for ; Tue, 17 Jan 2012 00:50:39 -0800 (PST) Received: from mail34-tx2-R.bigfish.com (10.9.14.251) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.23; Tue, 17 Jan 2012 08:50:31 +0000 Received: from mail34-tx2 (localhost [127.0.0.1]) by mail34-tx2-R.bigfish.com (Postfix) with ESMTP id 9B5006203B3 for ; Tue, 17 Jan 2012 08:50:32 +0000 (UTC) X-SpamScore: -19 X-BigFish: VS-19(zzc85fhzz1202hzz1033IL8275eh8275bh8275dha1495iz2fhc1ahc1bhc1ahc1bh2a8h668h839h62h) X-Spam-TCS-SCL: 1:0 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 Received-SPF: pass (mail34-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 mail34-tx2 (localhost.localdomain [127.0.0.1]) by mail34-tx2 (MessageSwitch) id 1326790231931093_14701; Tue, 17 Jan 2012 08:50:31 +0000 (UTC) Received: from TX2EHSMHS019.bigfish.com (unknown [10.9.14.254]) by mail34-tx2.bigfish.com (Postfix) with ESMTP id D778844004F for ; Tue, 17 Jan 2012 08:50:31 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS019.bigfish.com (10.9.99.119) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 17 Jan 2012 08:50:30 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.196]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0247.005; Tue, 17 Jan 2012 00:50:39 -0800 From: Mike Jones To: "jose@ietf.org" Thread-Topic: Initial Versions of JOSE Specs submitted Thread-Index: AczU9Q1ooM0QWv2jT1C+S+dMzdHedQ== Date: Tue, 17 Jan 2012 08:50:24 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366358444@TK5EX14MBXC285.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366358444TK5EX14MBXC285r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [jose] Initial Versions of JOSE Specs submitted X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.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, 17 Jan 2012 08:50:46 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366358444TK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've submitted initial IETF versions of the JOSE specs. Once the postings are approved by the chairs, they'll a= ppear as IETF -00 drafts. These specs are: * JSON Web Signature (JWS) - Digital signature/HMAC specification * JSON Web Encryption (JWE) - Encryption specification * JSON Web Key (JWK) - Public key specification * JSON Web Algorithms (JWA) - Algorithms and identifiers specificati= on They are refactored from the previous individual submission versions to mov= e algorithms and identifiers into a separate specification, per the working= group charter. Also, per th= e working group's input, the terminology usage has been changed to no longe= r call both digital signatures and HMACs "signatures". The JOSE versions c= ontain no normative changes from the individual submission versions. I've also posted submitted drafts at these locations: * http://self-issued.info/docs/draft-ietf-jose-json-web-signature-00= .html * http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-0= 0.html * http://self-issued.info/docs/draft-ietf-jose-json-web-key-00.html * http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-0= 0.html -- Mike --_000_4E1F6AAD24975D4BA5B168042967394366358444TK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve submitted initial IETF versions of the JOSE specs.  Once the postings are approved by the chairs, they= 217;ll appear as IETF -00 drafts.  These specs are:

·        JSON Web Signature (JWS) – Digital signature/HMAC specification

·        JSON Web Encryption (JWE)<= /span> – Encryption specification

·        JSON Web Key (JWK)<= span lang=3D"EN"> – Public key specification

·        JSON Web Algorithms= (JWA) – Algorithms and identifiers specification

 

They are refactored from the previous individual sub= mission versions to move algorithms and identifiers into a separate specifi= cation, per the working group char= ter.  Also, per the working group’s input, the terminology u= sage has been changed to no longer call both digital signatures and HMACs &= #8220;signatures”.  The JOSE versions contain no normative changes from the individual submission versions.

 

I’ve also posted submitted drafts at these loc= ations:

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

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

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

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

 

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

 

--_000_4E1F6AAD24975D4BA5B168042967394366358444TK5EX14MBXC285r_-- From internet-drafts@ietf.org Tue Jan 17 09:34: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 078B51F0C51; Tue, 17 Jan 2012 09:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7m+UqukXW9gc; Tue, 17 Jan 2012 09:34:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0E81F0C49; Tue, 17 Jan 2012 09:34:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120117173430.25105.23429.idtracker@ietfa.amsl.com> Date: Tue, 17 Jan 2012 09:34:30 -0800 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-signature-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, 17 Jan 2012 17:34:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encrypt= ion Working Group of the IETF. Title : JSON Web Signature (JWS) Author(s) : Michael B. Jones John Bradley Nat Sakimura Filename : draft-ietf-jose-json-web-signature-00.txt Pages : 27 Date : 2012-01-16 JSON Web Signature (JWS) is a means of representing content secured with digital signatures or Hash-based Message Authentication Codes (HMACs) using JSON data structures. Cryptographic algorithms and identifiers used with this specification are enumerated in the separate JSON Web Algorithms (JWA) specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-signature-00.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-jose-json-web-signature-00.txt From internet-drafts@ietf.org Tue Jan 17 09:35: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 47AA011E8089; Tue, 17 Jan 2012 09:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAHJm5jEYIwh; Tue, 17 Jan 2012 09:35:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2AE811E8072; Tue, 17 Jan 2012 09:35:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120117173533.25037.33548.idtracker@ietfa.amsl.com> Date: Tue, 17 Jan 2012 09:35:33 -0800 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-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, 17 Jan 2012 17:35:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encrypt= ion Working Group of the IETF. Title : JSON Web Encryption (JWE) Author(s) : Michael B. Jones Eric Rescorla Joe Hildebrand Filename : draft-ietf-jose-json-web-encryption-00.txt Pages : 18 Date : 2012-01-16 JSON Web Encryption (JWE) is a means of representing encrypted content using JSON data structures. Cryptographic algorithms and identifiers used with this specification are enumerated in the separate JSON Web Algorithms (JWA) specification. Related digital signature and HMAC capabilities are described in the separate JSON Web Signature (JWS) specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-encryption-00.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-jose-json-web-encryption-00.t= xt From internet-drafts@ietf.org Tue Jan 17 09:37: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 52E5921F85A5; Tue, 17 Jan 2012 09:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TO-LxnDm4tGn; Tue, 17 Jan 2012 09:37:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F06A321F857F; Tue, 17 Jan 2012 09:37:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120117173710.25610.53464.idtracker@ietfa.amsl.com> Date: Tue, 17 Jan 2012 09:37:10 -0800 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-key-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, 17 Jan 2012 17:37:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encrypt= ion Working Group of the IETF. Title : JSON Web Key (JWK) Author(s) : Michael B. Jones Filename : draft-ietf-jose-json-web-key-00.txt Pages : 8 Date : 2012-01-16 A JSON Web Key (JWK) is a JSON data structure that represents a set of public keys. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-key-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-jose-json-web-key-00.txt From ietf@augustcellars.com Tue Jan 17 17:12: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 B48DD21F86B9 for ; Tue, 17 Jan 2012 17:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 jgpE+mKuQ8pu for ; Tue, 17 Jan 2012 17:12:46 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 40E2021F86B6 for ; Tue, 17 Jan 2012 17:12:46 -0800 (PST) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (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 4AAC12CA2D for ; Tue, 17 Jan 2012 17:12:45 -0800 (PST) From: "Jim Schaad" To: Date: Tue, 17 Jan 2012 17:12:04 -0800 Message-ID: <014d01ccd57e$328f27e0$97ad77a0$@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: AczVfa7RHYgL4qdPS8qdwzXmCF/Jbg== Content-Language: en-us Subject: [jose] 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, 18 Jan 2012 01:12:46 -0000 I would like to see a mandatory AEAD algorithm. While I would prefer the use of AES-GCM, one algorithm that could be considered is the composite one purposed by Peter Gutmann in RFC 6476 which does the following: States separate encryption and MAC algorithms to be used Defines a method of deriving separate keys for the encryption and MAC algorithms from a single common key transported to the end user. This makes it appear as a standard AEAD algorithm but it is made up from common primitives rather than using a special mode that is not widely distributed. Jim From ve7jtb@ve7jtb.com Tue Jan 17 17:26: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 8B25B1F0C56 for ; Tue, 17 Jan 2012 17:26:09 -0800 (PST) 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 ZsjNgiBfLQj6 for ; Tue, 17 Jan 2012 17:26:09 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id EDDC41F0C35 for ; Tue, 17 Jan 2012 17:26:08 -0800 (PST) Received: by ghrr16 with SMTP id r16so1262423ghr.31 for ; Tue, 17 Jan 2012 17:26:07 -0800 (PST) Received: by 10.236.175.39 with SMTP id y27mr27602858yhl.86.1326849967313; Tue, 17 Jan 2012 17:26:07 -0800 (PST) Received: from [192.168.1.213] ([190.22.86.51]) by mx.google.com with ESMTPS id a7sm64962922ana.5.2012.01.17.17.26.05 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Jan 2012 17:26:06 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_58F0BAA4-7723-41A6-8D15-DDF3FD974107"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <014d01ccd57e$328f27e0$97ad77a0$@augustcellars.com> Date: Tue, 17 Jan 2012 22:26:03 -0300 Message-Id: <3E9ED177-C7B5-4567-BC28-993DC28073F2@ve7jtb.com> References: <014d01ccd57e$328f27e0$97ad77a0$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1251.1) Cc: jose@ietf.org Subject: Re: [jose] 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, 18 Jan 2012 01:26:09 -0000 --Apple-Mail=_58F0BAA4-7723-41A6-8D15-DDF3FD974107 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I agree that is needed for JWE. The goal of this draft was to add nothing new to the existing JWE & JWS = specs. I expect that the next draft will add a MTI AEAD algorithm. John B. On 2012-01-17, at 10:12 PM, Jim Schaad wrote: > I would like to see a mandatory AEAD algorithm. While I would prefer = the use > of AES-GCM, one algorithm that could be considered is the composite = one > purposed by Peter Gutmann in RFC 6476 which does the following: >=20 > States separate encryption and MAC algorithms to be used > Defines a method of deriving separate keys for the encryption and MAC > algorithms from a single common key transported to the end user. >=20 > This makes it appear as a standard AEAD algorithm but it is made up = from > common primitives rather than using a special mode that is not widely > distributed. >=20 > Jim >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_58F0BAA4-7723-41A6-8D15-DDF3FD974107 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAx MTgwMTI2MDNaMCMGCSqGSIb3DQEJBDEWBBQZe4H6itMNg8fqxJJKrdd2dxhu7jCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQBOVydip93KVhHNDZk1axK7zLv8fH9YrjpFxCO/KyN3Kk6iL6uZW6yt7HpaF49vaEg0lAwcFQfu llBf+sAd3L0VvabMn5/F7+QF6J3B13aFP2QagUkS9vwct1a6dmTL+OdLu+/IZliDzVz9PS5FdtFe G9laXuhVGLnH+0uSdTtUmNIik3PLCdalGHjVzy4if4Gkx5XL4d6cwlidGz1ISvv8KcI8/KfgDQGD U0cmD2wPYa7x/N+xGKLbljuLypsds9L23b9L61AQ2MZvNwBcwgvXbAWZN4lsxK3JE+aymMcdTvlH 1v7yduLnyilX3281BXzjyB2y1Ab0Hlkuerm1hU+VAAAAAAAA --Apple-Mail=_58F0BAA4-7723-41A6-8D15-DDF3FD974107-- From yaronf.ietf@gmail.com Tue Jan 17 23:26: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 C392F21F84E1 for ; Tue, 17 Jan 2012 23:26:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 M5jenSeiCi+N for ; Tue, 17 Jan 2012 23:26:47 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 703FC21F84D7 for ; Tue, 17 Jan 2012 23:26:47 -0800 (PST) Received: by eeit10 with SMTP id t10so1613560eei.31 for ; Tue, 17 Jan 2012 23:26:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=kcQryQH5n2y6jajbuxwSsne0rFER4rTEIDdDDPUIThY=; b=Zvv6nA4ljS5kMyI4bfcLNcgxNOkREjl4JMJyE+N3JX8FO5uxs+yO1hJBYPhXb+WdCG R0Ds7aGotRVYQLwpNq/ITg2leAUvELwFdGMltu2JW8q5JnYf1yBmgOI2//bbgN3vGXGa 5kEi1b69nCVSuJIyiy8BFSKjHHHownhwXiFGM= Received: by 10.213.108.141 with SMTP id f13mr4982008ebp.112.1326871606136; Tue, 17 Jan 2012 23:26:46 -0800 (PST) Received: from [10.0.0.6] (bzq-79-183-174-22.red.bezeqint.net. [79.183.174.22]) by mx.google.com with ESMTPS id e12sm96350748eea.5.2012.01.17.23.26.44 (version=SSLv3 cipher=OTHER); Tue, 17 Jan 2012 23:26:45 -0800 (PST) Message-ID: <4F167432.1030503@gmail.com> Date: Wed, 18 Jan 2012 09:26:42 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: jose@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [jose] Comments on the JOSE drafts X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 07:26:48 -0000 Hi, below is a set of comments on the new drafts. I am new to this list, and I apologize if these issues have already beaten to death. draft-ietf-jose-json-web-key-00 * This is probably water under the bridge by now, but I think the applicability of bare public keys (as opposed to certificates and certificate chains) is very limited. And there is value in using the mechanisms defined here for certificate (and not just public key) roll-over. * In addition, integrity protection and encryption with symmetric keys is also extremely useful. For example, this format could be used for Kerberos-like authorization tickets. * Why mention specifically RSA and Elliptic Curve, instead of building on (a subset of) PKCS#8, which is more generic? For example, someone's bound to require modular DSA at some point. * "EC" is not an algorithm. You probably mean "ECDSA" (e.g. as opposed to ECDH). * The way we propose to deal with additional, unknown members precludes extensibility. One can easily think of meaningful optional members (e.g. key owner, key version) that do NOT need to be understood by most consumers. draft-ietf-jose-json-web-signature-00 * Again, why mention HMAC already in the introduction, vs. the more generic "message authentication code". * Can the payload be binary? The Terminology should clarify it. * The definition of JWS Header is self-referential and confusing. * "Computing the HMAC of the UTF-8 representation": this is a bit misleading - the representation is actually good old ASCII. * In the same paragraph, computing HMAC-256 also requires a key, which should have been mentioned. * When defining the jku member: RFC 6125 is very new - do we really have to make it mandatory here? * No way is defined to name symmetric keys used for HMAC signatures. * I suggest to rename x5t to something that includes the algorithm, e.g. "x5t_sha1". We have already migrated from MD5 to SHA-1, there will be more coming. But the idea of using key names instead of the full key is valuable. * Again, step #3 of the JWS validation process precludes easy extensibility. In many cases you do NOT want the signature consumer to understand all the fields. In particular when some parameters ("typ") are underspecified. * IANA considerations: why not define a way for implementations to have member names that are guaranteed *not* to become reserved? Something like "x-*"? URIs are simply too long. * Also, it is very important to allow for IANA extensibility of the set of supported algorithms (probably in the forthcoming JWA document). draft-ietf-jose-json-web-encryption-00 * Many people are still not using authenticated-encryption algorithms. Such people are very likely to abuse this specification, i.e. use just encryption with no integrity protection (yes, despite the SHOULD wording at the bottom of the document). IMHO this spec must also support the more traditional usage of encryption+MAC. Integrity protection should not be left as an implementer's option. * 4.2: this paragraph talks about parameter names, but also sneaks in algorithm names, which probably require a separate IANA registry and possibly separate extensibility rules. I suggest to separate them out. * 5: in steps #5 and #6, this is not a bitstring, it's a byte string (or a "sequence of octets"). * 6: the decryption step (#6) also includes validation of the AES-GCM authentication tag, and this may fail of course. * 7.2: OK, the algorithm can be specified, but how do we reference the key being used, and its version number? * As far as I know "randomness in browsers... is easy to screw up" is actually an understatement. It is still impossible to do, at least not in a portable way. From hannes.tschofenig@gmx.net Tue Jan 17 23:59: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 7E64F21F8724 for ; Tue, 17 Jan 2012 23:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.033 X-Spam-Level: X-Spam-Status: No, score=-102.033 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, 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 BvGH++4+OI4F for ; Tue, 17 Jan 2012 23:59:05 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 8BB4C21F8722 for ; Tue, 17 Jan 2012 23:59:04 -0800 (PST) Received: (qmail invoked by alias); 18 Jan 2012 07:59:02 -0000 Received: from unknown (EHLO [10.255.134.84]) [192.100.123.77] by mail.gmx.net (mp071) with SMTP; 18 Jan 2012 08:59:02 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX199VNd23RJ9hCnSAqNXMDZ2lsAxC9X9/A1eHFYzcP upl1EvSJ+8tgGA Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <014d01ccd57e$328f27e0$97ad77a0$@augustcellars.com> Date: Wed, 18 Jan 2012 09:58:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <014d01ccd57e$328f27e0$97ad77a0$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: Hannes Tschofenig , jose@ietf.org Subject: Re: [jose] 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, 18 Jan 2012 07:59:05 -0000 Hi Jim,=20 when you say "mandatory" what do you mean?=20 Already for a while now we are not putting mandatory to implement nor = mandatory to use algorithms in our specifications anymore.=20 See also my mail to the OAuth list on that topic: http://www.ietf.org/mail-archive/web/oauth/current/msg08019.html Ciao Hanns On Jan 18, 2012, at 3:12 AM, Jim Schaad wrote: > I would like to see a mandatory AEAD algorithm. While I would prefer = the use > of AES-GCM, one algorithm that could be considered is the composite = one > purposed by Peter Gutmann in RFC 6476 which does the following: >=20 > States separate encryption and MAC algorithms to be used > Defines a method of deriving separate keys for the encryption and MAC > algorithms from a single common key transported to the end user. >=20 > This makes it appear as a standard AEAD algorithm but it is made up = from > common primitives rather than using a special mode that is not widely > distributed. >=20 > Jim >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From ietf@augustcellars.com Wed Jan 18 00:44: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 0951521F86EF for ; Wed, 18 Jan 2012 00:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.279 X-Spam-Level: X-Spam-Status: No, score=-3.279 tagged_above=-999 required=5 tests=[AWL=0.320, 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 X+JBr9qPFzKq for ; Wed, 18 Jan 2012 00:44:43 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 750B621F86EB for ; Wed, 18 Jan 2012 00:44:43 -0800 (PST) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (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 0DD7E2CA3C; Wed, 18 Jan 2012 00:44:43 -0800 (PST) From: "Jim Schaad" To: "'Hannes Tschofenig'" References: <014d01ccd57e$328f27e0$97ad77a0$@augustcellars.com> In-Reply-To: Date: Wed, 18 Jan 2012 00:44:03 -0800 Message-ID: <016f01ccd5bd$5563a270$002ae750$@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: AQHpQafquGgRxYgqQQw7kfl6wHzTdAHuUeWRlcmCjKA= Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] 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, 18 Jan 2012 08:44:44 -0000 It is not quite true that we do not put mandatory to implement algorithms in our specs any more. The requirement to have mandated algorithms varies depending on the specification and the purpose to which it is to be used. It is true that PKIX and CMS do not have mandated algorithms, but S/MIME, TLS and DANE do. The difference is generally a question of are we just defining a frame work or a protocol. In this case we are separating the algorithms from the structure, but I think that the group as a whole may decide that it will still need to specify a set of mandatory algorithms in order to promote interoperability as a library. Documents which build on top, such as the JSON token document might or might not specify the same, different or any algorithms (inheriting what we do). I have not yet formulated a final personal opinion, but the language I have heard in the past on the list is towards specifying mandatory algorithms. Jim > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Tuesday, January 17, 2012 11:59 PM > To: Jim Schaad > Cc: Hannes Tschofenig; jose@ietf.org > Subject: Re: [jose] AEAD algorithms > > Hi Jim, > > when you say "mandatory" what do you mean? > > Already for a while now we are not putting mandatory to implement nor > mandatory to use algorithms in our specifications anymore. > > See also my mail to the OAuth list on that topic: > http://www.ietf.org/mail-archive/web/oauth/current/msg08019.html > > Ciao > Hanns > > On Jan 18, 2012, at 3:12 AM, Jim Schaad wrote: > > > I would like to see a mandatory AEAD algorithm. While I would prefer > > the use of AES-GCM, one algorithm that could be considered is the > > composite one purposed by Peter Gutmann in RFC 6476 which does the > following: > > > > States separate encryption and MAC algorithms to be used Defines a > > method of deriving separate keys for the encryption and MAC algorithms > > from a single common key transported to the end user. > > > > This makes it appear as a standard AEAD algorithm but it is made up > > from common primitives rather than using a special mode that is not > > widely distributed. > > > > Jim > > > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Wed Jan 18 01:02: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 39B4721F858A for ; Wed, 18 Jan 2012 01:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.634 X-Spam-Level: X-Spam-Status: No, score=-3.634 tagged_above=-999 required=5 tests=[AWL=-0.035, 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 vprrtlns6hHh for ; Wed, 18 Jan 2012 01:02:23 -0800 (PST) Received: from VA3EHSOBE002.bigfish.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA9B21F8585 for ; Wed, 18 Jan 2012 01:02:23 -0800 (PST) Received: from mail144-va3-R.bigfish.com (10.7.14.248) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Wed, 18 Jan 2012 09:02:15 +0000 Received: from mail144-va3 (localhost [127.0.0.1]) by mail144-va3-R.bigfish.com (Postfix) with ESMTP id F2A912C007E; Wed, 18 Jan 2012 09:02:20 +0000 (UTC) X-SpamScore: -39 X-BigFish: VS-39(zz9371I542M1432N1418M98dKzz1202hzz1033IL8275eh8275dha1495iz2fhc1ahc1bh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail144-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=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail144-va3 (localhost.localdomain [127.0.0.1]) by mail144-va3 (MessageSwitch) id 1326877338812692_2188; Wed, 18 Jan 2012 09:02:18 +0000 (UTC) Received: from VA3EHSMHS031.bigfish.com (unknown [10.7.14.240]) by mail144-va3.bigfish.com (Postfix) with ESMTP id BFE4144004A; Wed, 18 Jan 2012 09:02:18 +0000 (UTC) Received: from TK5EX14HUBC107.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; Wed, 18 Jan 2012 09:02:10 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.196]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0247.005; Wed, 18 Jan 2012 01:02:13 -0800 From: Mike Jones To: Jim Schaad , 'Hannes Tschofenig' Thread-Topic: [jose] AEAD algorithms Thread-Index: AczVfa7RHYgL4qdPS8qdwzXmCF/JbgAfGbqAAAGTOoAAEKOn8A== Date: Wed, 18 Jan 2012 09:02:12 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436635F4AF@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <014d01ccd57e$328f27e0$97ad77a0$@augustcellars.com> <016f01ccd5bd$5563a270$002ae750$@augustcellars.com> In-Reply-To: <016f01ccd5bd$5563a270$002ae750$@augustcellars.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] 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, 18 Jan 2012 09:02:24 -0000 As a data point, the current specs DO specify mandatory-to-implement algori= thms to promote interoperability. See http://self-issued.info/docs/draft-i= etf-jose-json-web-algorithms-00.html#SigningAlgs and http://self-issued.inf= o/docs/draft-ietf-jose-json-web-algorithms-00.html#EncryptingAlgs. The key= sentences are: For JWS: Of these algorithms, only HMAC SHA-256 MUST be implemented by con= forming JWS implementations. It is RECOMMENDED that implementations also su= pport the RSA SHA-256 and ECDSA P-256 SHA-256 algorithms. Support for other= algorithms and key sizes is OPTIONAL. For JWE: Of these algorithms, only RSA-PKCS1-1.5 with 2048 bit keys, AES-1= 28-CBC, and AES-256-CBC MUST be implemented by conforming JWE implementatio= ns. It is RECOMMENDED that implementations also support ECDH-ES with 256 bi= t keys, AES-128-GCM, and AES-256-GCM. Support for other algorithms and key = sizes is OPTIONAL. -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad Sent: Wednesday, January 18, 2012 12:44 AM To: 'Hannes Tschofenig' Cc: jose@ietf.org Subject: Re: [jose] AEAD algorithms It is not quite true that we do not put mandatory to implement algorithms i= n our specs any more. The requirement to have mandated algorithms varies d= epending on the specification and the purpose to which it is to be used. It is true that PKIX and CMS do not have mandated algorithms, but S/MIME, T= LS and DANE do. The difference is generally a question of are we just defi= ning a frame work or a protocol. =20 In this case we are separating the algorithms from the structure, but I thi= nk that the group as a whole may decide that it will still need to specify = a set of mandatory algorithms in order to promote interoperability as a lib= rary. Documents which build on top, such as the JSON token document might = or might not specify the same, different or any algorithms (inheriting what= we do).=20 I have not yet formulated a final personal opinion, but the language I have= heard in the past on the list is towards specifying mandatory algorithms. Jim > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Tuesday, January 17, 2012 11:59 PM > To: Jim Schaad > Cc: Hannes Tschofenig; jose@ietf.org > Subject: Re: [jose] AEAD algorithms >=20 > Hi Jim, >=20 > when you say "mandatory" what do you mean? >=20 > Already for a while now we are not putting mandatory to implement nor=20 > mandatory to use algorithms in our specifications anymore. >=20 > See also my mail to the OAuth list on that topic: > http://www.ietf.org/mail-archive/web/oauth/current/msg08019.html >=20 > Ciao > Hanns >=20 > On Jan 18, 2012, at 3:12 AM, Jim Schaad wrote: >=20 > > I would like to see a mandatory AEAD algorithm. While I would prefer=20 > > the use of AES-GCM, one algorithm that could be considered is the=20 > > composite one purposed by Peter Gutmann in RFC 6476 which does the > following: > > > > States separate encryption and MAC algorithms to be used Defines a=20 > > method of deriving separate keys for the encryption and MAC=20 > > algorithms from a single common key transported to the end user. > > > > This makes it appear as a standard AEAD algorithm but it is made up=20 > > from common primitives rather than using a special mode that is not=20 > > widely distributed. > > > > Jim > > > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From hannes.tschofenig@gmx.net Wed Jan 18 01:10: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 0FE1E21F8775 for ; Wed, 18 Jan 2012 01:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.025 X-Spam-Level: X-Spam-Status: No, score=-102.025 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, 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 ZPSdicwmuuWo for ; Wed, 18 Jan 2012 01:10:55 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 2102521F8773 for ; Wed, 18 Jan 2012 01:10:54 -0800 (PST) Received: (qmail invoked by alias); 18 Jan 2012 09:10:52 -0000 Received: from unknown (EHLO [10.255.134.84]) [192.100.123.77] by mail.gmx.net (mp072) with SMTP; 18 Jan 2012 10:10:52 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19kpZ0BKyJkyUY4C7HbBsKdkb8XcL0uhArU1JYjm0 n11Px05kF7yWkC Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <016f01ccd5bd$5563a270$002ae750$@augustcellars.com> Date: Wed, 18 Jan 2012 11:10:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <014d01ccd57e$328f27e0$97ad77a0$@augustcellars.com> <016f01ccd5bd$5563a270$002ae750$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: Hannes Tschofenig , jose@ietf.org Subject: Re: [jose] 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, 18 Jan 2012 09:10:56 -0000 While I disagree with you even in case of TLS I definitely think that = JOSE should list mandatory-to-implement or mandatory-to-use algorithms = in the main documents. You can always write an additional document that = lists what algorithms are recommended for usage in specific environments = and update that document every few years.=20 On Jan 18, 2012, at 10:44 AM, Jim Schaad wrote: > >=20 > It is not quite true that we do not put mandatory to implement = algorithms in > our specs any more. The requirement to have mandated algorithms = varies > depending on the specification and the purpose to which it is to be = used. > It is true that PKIX and CMS do not have mandated algorithms, but = S/MIME, > TLS and DANE do. The difference is generally a question of are we = just > defining a frame work or a protocol. =20 >=20 > In this case we are separating the algorithms from the structure, but = I > think that the group as a whole may decide that it will still need to > specify a set of mandatory algorithms in order to promote = interoperability > as a library. Documents which build on top, such as the JSON token = document > might or might not specify the same, different or any algorithms = (inheriting > what we do).=20 >=20 > I have not yet formulated a final personal opinion, but the language I = have > heard in the past on the list is towards specifying mandatory = algorithms. >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] >> Sent: Tuesday, January 17, 2012 11:59 PM >> To: Jim Schaad >> Cc: Hannes Tschofenig; jose@ietf.org >> Subject: Re: [jose] AEAD algorithms >>=20 >> Hi Jim, >>=20 >> when you say "mandatory" what do you mean? >>=20 >> Already for a while now we are not putting mandatory to implement nor >> mandatory to use algorithms in our specifications anymore. >>=20 >> See also my mail to the OAuth list on that topic: >> http://www.ietf.org/mail-archive/web/oauth/current/msg08019.html >>=20 >> Ciao >> Hanns >>=20 >> On Jan 18, 2012, at 3:12 AM, Jim Schaad wrote: >>=20 >>> I would like to see a mandatory AEAD algorithm. While I would prefer >>> the use of AES-GCM, one algorithm that could be considered is the >>> composite one purposed by Peter Gutmann in RFC 6476 which does the >> following: >>>=20 >>> States separate encryption and MAC algorithms to be used Defines a >>> method of deriving separate keys for the encryption and MAC = algorithms >>> from a single common key transported to the end user. >>>=20 >>> This makes it appear as a standard AEAD algorithm but it is made up >>> from common primitives rather than using a special mode that is not >>> widely distributed. >>>=20 >>> Jim >>>=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 cabo@tzi.org Wed Jan 18 03:37: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 52E6F21F87EC for ; Wed, 18 Jan 2012 03:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 bjiCX4p++ErK for ; Wed, 18 Jan 2012 03:37:45 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 8221621F87EB for ; Wed, 18 Jan 2012 03:37:45 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q0IBauYI020983; Wed, 18 Jan 2012 12:36:56 +0100 (CET) Received: from [10.0.1.3] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 144FFAAD; Wed, 18 Jan 2012 12:36:56 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 18 Jan 2012 12:36:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <62BFE90E-1659-4581-B9B3-81CA735BF2DC@tzi.org> References: <014d01ccd57e$328f27e0$97ad77a0$@augustcellars.com> <016f01ccd5bd$5563a270$002ae750$@augustcellars.com> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1251.1) Cc: Jim Schaad , jose@ietf.org Subject: Re: [jose] 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, 18 Jan 2012 11:37:46 -0000 On Jan 18, 2012, at 10:10, Hannes Tschofenig wrote: > While I disagree with you even in case of TLS I definitely think that = JOSE should list mandatory-to-implement or mandatory-to-use algorithms = in the main documents. You can always write an additional document that = lists what algorithms are recommended for usage in specific environments = and update that document every few years.=20 Well, I don't know (or did you mean "should not"?). For constrained devices with current chip sets, there is a very strong = bias in favor of AES-CCM. I don't think any MTI algorithms should be defined without also a bit = more explicit about the area of application. (Yes, we do want to use JOSE in constrained devices. That is hard = enough!) Gr=FC=DFe, Carsten From hannes.tschofenig@gmx.net Wed Jan 18 03:52: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 C8C6621F8734 for ; Wed, 18 Jan 2012 03:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOelxydzpSg9 for ; Wed, 18 Jan 2012 03:52:54 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id EBF3C21F872E for ; Wed, 18 Jan 2012 03:52:53 -0800 (PST) Received: (qmail invoked by alias); 18 Jan 2012 11:52:51 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.103]) [88.115.216.191] by mail.gmx.net (mp023) with SMTP; 18 Jan 2012 12:52:51 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/7dlp8zl377pVTtf7gdmFaDGeLIowblMmm/9mXll yC5sP5C0f0oeAZ Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Hannes Tschofenig In-Reply-To: <62BFE90E-1659-4581-B9B3-81CA735BF2DC@tzi.org> Date: Wed, 18 Jan 2012 13:52:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1403E8AF-DBC1-42ED-BFC3-A717B5B5FCF2@gmx.net> References: <014d01ccd57e$328f27e0$97ad77a0$@augustcellars.com> <016f01ccd5bd$5563a270$002ae750$@augustcellars.com> <62BFE90E-1659-4581-B9B3-81CA735BF2DC@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: Jim Schaad , Hannes Tschofenig , jose@ietf.org Subject: Re: [jose] 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, 18 Jan 2012 11:52:54 -0000 Hi Carsten,=20 that's exactly the problem: for some environments certain algorithms are = best suited and in others they are not.=20 You have to describe the envisioned environment and make the = recommendation for it=20 Then, you also want to avoid updating a protocol specification whenever = you want to add a new use case or when algorithms are out-of-fashion. Ciao Hannes On Jan 18, 2012, at 1:36 PM, Carsten Bormann wrote: > On Jan 18, 2012, at 10:10, Hannes Tschofenig wrote: >=20 >> While I disagree with you even in case of TLS I definitely think that = JOSE should list mandatory-to-implement or mandatory-to-use algorithms = in the main documents. You can always write an additional document that = lists what algorithms are recommended for usage in specific environments = and update that document every few years.=20 >=20 > Well, I don't know (or did you mean "should not"?). >=20 > For constrained devices with current chip sets, there is a very strong = bias in favor of AES-CCM. > I don't think any MTI algorithms should be defined without also a bit = more explicit about the area of application. > (Yes, we do want to use JOSE in constrained devices. That is hard = enough!) >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From internet-drafts@ietf.org Wed Jan 18 13:04: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 C5F2421F8595; Wed, 18 Jan 2012 13:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6S0YoZPZtFC8; Wed, 18 Jan 2012 13:04:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8DD21F8523; Wed, 18 Jan 2012 13:04:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120118210436.23621.37845.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2012 13:04:36 -0800 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-algorithms-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, 18 Jan 2012 21:04:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encrypt= ion Working Group of the IETF. Title : JSON Web Algorithms (JWA) Author(s) : Michael B. Jones Filename : draft-ietf-jose-json-web-algorithms-00.txt Pages : 19 Date : 2012-01-16 The JSON Web Algorithms (JWA) specification enumerates cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS) and JSON Web Encryption (JWE) specifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-algorithms-00.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-jose-json-web-algorithms-00.t= xt From tony@att.com Wed Jan 18 13:11: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 39E7511E80A6 for ; Wed, 18 Jan 2012 13:11:51 -0800 (PST) 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 k203XRag+IAD for ; Wed, 18 Jan 2012 13:11:50 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 408FE11E809D for ; Wed, 18 Jan 2012 13:11:50 -0800 (PST) X-Env-Sender: tony@att.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1326921109!11185835!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.4.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27654 invoked from network); 18 Jan 2012 21:11:49 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-15.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Jan 2012 21:11:49 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q0ILCIvq023094 for ; Wed, 18 Jan 2012 16:12:18 -0500 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q0ILCCO7022993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 Jan 2012 16:12:13 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor) for ; Wed, 18 Jan 2012 16:11:32 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q0ILBWRT011043 for ; Wed, 18 Jan 2012 16:11:32 -0500 Received: from mailgw1.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q0ILBTgc010772 for ; Wed, 18 Jan 2012 16:11:29 -0500 Received: from [135.91.110.247] (ilpdsl01rw0090.ugd.att.com[135.91.110.247]) by maillennium.att.com (mailgw1) with ESMTP id <20120118210938gw100e4ltbe> (Authid: tony); Wed, 18 Jan 2012 21:09:38 +0000 X-Originating-IP: [135.91.110.247] Message-ID: <4F173580.6070409@att.com> Date: Wed, 18 Jan 2012 16:11:28 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: jose@ietf.org References: <20120118210436.23621.37845.idtracker@ietfa.amsl.com> In-Reply-To: <20120118210436.23621.37845.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-algorithms-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, 18 Jan 2012 21:11:51 -0000 For some reason, this doc got "stuck" in the queue. Let the comments begin! Tony Hansen your friendly co-chair On 1/18/2012 4:04 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Javascript Object Signing and Encryption Working Group of the IETF. > > Title : JSON Web Algorithms (JWA) > Author(s) : Michael B. Jones > Filename : draft-ietf-jose-json-web-algorithms-00.txt > Pages : 19 > Date : 2012-01-16 > > The JSON Web Algorithms (JWA) specification enumerates cryptographic > algorithms and identifiers to be used with the JSON Web Signature > (JWS) and JSON Web Encryption (JWE) specifications. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-algorithms-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-jose-json-web-algorithms-00.txt > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Wed Jan 18 13:50: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 7220E11E80B0 for ; Wed, 18 Jan 2012 13:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.132 X-Spam-Level: X-Spam-Status: No, score=-5.132 tagged_above=-999 required=5 tests=[AWL=1.466, 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 vlFYbiDnXM1q for ; Wed, 18 Jan 2012 13:50:01 -0800 (PST) Received: from VA3EHSOBE007.bigfish.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 71AEB11E807F for ; Wed, 18 Jan 2012 13:50:01 -0800 (PST) Received: from mail8-va3-R.bigfish.com (10.7.14.245) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.23; Wed, 18 Jan 2012 21:50:00 +0000 Received: from mail8-va3 (localhost [127.0.0.1]) by mail8-va3-R.bigfish.com (Postfix) with ESMTP id 6705C700399 for ; Wed, 18 Jan 2012 21:50:00 +0000 (UTC) X-SpamScore: -25 X-BigFish: VS-25(zz9371Ic85fh1b0bMzz1202hzz1033IL8275eh8275bh8275dha1495iz2fhc1bhc31hc1ahc1bhc31hc1ah2a8h668h839h) 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 Received-SPF: pass (mail8-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=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail8-va3 (localhost.localdomain [127.0.0.1]) by mail8-va3 (MessageSwitch) id 132692339884957_18446; Wed, 18 Jan 2012 21:49:58 +0000 (UTC) Received: from VA3EHSMHS010.bigfish.com (unknown [10.7.14.249]) by mail8-va3.bigfish.com (Postfix) with ESMTP id 05847640086 for ; Wed, 18 Jan 2012 21:49:58 +0000 (UTC) Received: from TK5EX14HUBC101.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; Wed, 18 Jan 2012 21:49:56 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.196]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0247.005; Wed, 18 Jan 2012 13:49:47 -0800 From: Mike Jones To: "jose@ietf.org" Thread-Topic: Initial Versions of JOSE Specs submitted Thread-Index: AczWKxXq2MKM0AA5QNCiz+atnQIrsg== Date: Wed, 18 Jan 2012 21:49:46 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366360028@TK5EX14MBXC285.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366360028TK5EX14MBXC285r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] Initial Versions of JOSE Specs submitted X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 21:50:03 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366360028TK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, the posted IETF versions are now available at these locations: * http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-00 * http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-00 * http://tools.ietf.org/html/draft-ietf-jose-json-web-key-00 * http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-00 -- Mike From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Mike Jone= s Sent: Tuesday, January 17, 2012 12:50 AM To: jose@ietf.org Subject: [jose] Initial Versions of JOSE Specs submitted I've submitted initial IETF versions of the JOSE specs. Once the postings are approved by the chairs, they'll a= ppear as IETF -00 drafts. These specs are: * JSON Web Signature (JWS) - Digital signature/HMAC specification * JSON Web Encryption (JWE) - Encryption specification * JSON Web Key (JWK) - Public key specification * JSON Web Algorithms (JWA) - Algorithms and identifiers specificati= on They are refactored from the previous individual submission versions to mov= e algorithms and identifiers into a separate specification, per the working= group charter. Also, per th= e working group's input, the terminology usage has been changed to no longe= r call both digital signatures and HMACs "signatures". The JOSE versions c= ontain no normative changes from the individual submission versions. I've also posted submitted drafts at these locations: * http://self-issued.info/docs/draft-ietf-jose-json-web-signature-00= .html * http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-0= 0.html * http://self-issued.info/docs/draft-ietf-jose-json-web-key-00.html * http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-0= 0.html -- Mike --_000_4E1F6AAD24975D4BA5B168042967394366360028TK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI, the posted IETF v= ersions are now available at these locations:

·        http://tools= .ietf.org/html/draft-ietf-jose-json-web-signature-00<= /p>

·        http://tool= s.ietf.org/html/draft-ietf-jose-json-web-encryption-00

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

·        http://tool= s.ietf.org/html/draft-ietf-jose-json-web-algorithms-00

 

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

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Tuesday, January 17, 2012 12:50 AM
To: jose@ietf.org
Subject: [jose] Initial Versions of JOSE Specs submitted<= /span>

 

I’ve submitted initial IETF versions of the JOSE specs.  Once the postings are approved by the chairs, they= 217;ll appear as IETF -00 drafts.  These specs are:

·        JSON Web Signature (JWS) <= /span>– Digital signature/HMAC specification

·        JSON Web Encryption (JWE) = – Encryption specification

·        JSON Web Key (JWK) = – Public key specification

·        JSON Web Algorithms= (JWA) – Algorithms and identifiers specification

 

They are refactored from the previous individual sub= mission versions to move algorithms and identifiers into a separate specifi= cation, per the working group char= ter.  Also, per the working group’s input, the terminology u= sage has been changed to no longer call both digital signatures and HMACs &= #8220;signatures”.  The JOSE versions contain no normative changes from the individual submission versions.

 

I’ve also posted submitted drafts at these loc= ations:

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

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

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

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

 

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

 

--_000_4E1F6AAD24975D4BA5B168042967394366360028TK5EX14MBXC285r_-- From ekr@rtfm.com Wed Jan 18 14:45: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 282E011E80B0 for ; Wed, 18 Jan 2012 14:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.846 X-Spam-Level: X-Spam-Status: No, score=-102.846 tagged_above=-999 required=5 tests=[AWL=0.131, 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 CV2rVpLH3aSQ for ; Wed, 18 Jan 2012 14:45:04 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9D911E80A2 for ; Wed, 18 Jan 2012 14:45:04 -0800 (PST) Received: by vcbfk26 with SMTP id fk26so3020971vcb.31 for ; Wed, 18 Jan 2012 14:45:02 -0800 (PST) Received: by 10.220.116.10 with SMTP id k10mr5081714vcq.25.1326926701212; Wed, 18 Jan 2012 14:45:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.93.163 with HTTP; Wed, 18 Jan 2012 14:44:20 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <014d01ccd57e$328f27e0$97ad77a0$@augustcellars.com> <016f01ccd5bd$5563a270$002ae750$@augustcellars.com> From: Eric Rescorla Date: Wed, 18 Jan 2012 14:44:20 -0800 Message-ID: To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Jim Schaad , jose@ietf.org Subject: Re: [jose] 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, 18 Jan 2012 22:45:05 -0000 On Wed, Jan 18, 2012 at 1:10 AM, Hannes Tschofenig wrote: > While I disagree with you even in case of TLS I definitely think that JOS= E should list mandatory-to-implement or mandatory-to-use algorithms in the = main documents. You can always write an additional document that lists what= algorithms are recommended for usage in specific environments and update t= hat document every few years. I don't understand what you disagree with in the case of TLS. TLS does define an MTI. See: http://tools.ietf.org/html/rfc5246#section-9 Perhaps your argument is that TLS shouldn't do this. However, that's quite different from the statement that we are not doing so, with which, like Jim, I don't agree. -Ekr > On Jan 18, 2012, at 10:44 AM, Jim Schaad wrote: > >> >> >> It is not quite true that we do not put mandatory to implement algorithm= s in >> our specs any more. =A0The requirement to have mandated algorithms varie= s >> depending on the specification and the purpose to which it is to be used= . >> It is true that PKIX and CMS do not have mandated algorithms, but S/MIME= , >> TLS and DANE do. =A0The difference is generally a question of are we jus= t >> defining a frame work or a protocol. >> >> In this case we are separating the algorithms from the structure, but I >> think that the group as a whole may decide that it will still need to >> specify a set of mandatory algorithms in order to promote interoperabili= ty >> as a library. =A0Documents which build on top, such as the JSON token do= cument >> might or might not specify the same, different or any algorithms (inheri= ting >> what we do). >> >> I have not yet formulated a final personal opinion, but the language I h= ave >> heard in the past on the list is towards specifying mandatory algorithms= . >> >> Jim >> >> >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] >>> Sent: Tuesday, January 17, 2012 11:59 PM >>> To: Jim Schaad >>> Cc: Hannes Tschofenig; jose@ietf.org >>> Subject: Re: [jose] AEAD algorithms >>> >>> Hi Jim, >>> >>> when you say "mandatory" what do you mean? >>> >>> Already for a while now we are not putting mandatory to implement nor >>> mandatory to use algorithms in our specifications anymore. >>> >>> See also my mail to the OAuth list on that topic: >>> http://www.ietf.org/mail-archive/web/oauth/current/msg08019.html >>> >>> Ciao >>> Hanns >>> >>> On Jan 18, 2012, at 3:12 AM, Jim Schaad wrote: >>> >>>> I would like to see a mandatory AEAD algorithm. While I would prefer >>>> the use of AES-GCM, one algorithm that could be considered is the >>>> composite one purposed by Peter Gutmann in RFC 6476 which does the >>> following: >>>> >>>> States separate encryption and MAC algorithms to be used Defines a >>>> method of deriving separate keys for the encryption and MAC algorithms >>>> from a single common key transported to the end user. >>>> >>>> This makes it appear as a standard AEAD algorithm but it is made up >>>> from common primitives rather than using a special mode that is not >>>> widely distributed. >>>> >>>> Jim >>>> >>>> >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose