Re: [jose] RSASSA-PSS signature

Mike Jones <Michael.Jones@microsoft.com> Tue, 12 March 2013 20:12 UTC

Return-Path: <Michael.Jones@microsoft.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF5211E8167 for <jose@ietfa.amsl.com>; Tue, 12 Mar 2013 13:12:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkpsSTet9a1v for <jose@ietfa.amsl.com>; Tue, 12 Mar 2013 13:12:21 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) by ietfa.amsl.com (Postfix) with ESMTP id 79A0D11E8164 for <jose@ietf.org>; Tue, 12 Mar 2013 13:12:21 -0700 (PDT)
Received: from BN1AFFO11FD008.protection.gbl (10.58.52.200) by BN1AFFO11HUB021.protection.gbl (10.58.52.131) with Microsoft SMTP Server (TLS) id 15.0.620.12; Tue, 12 Mar 2013 20:12:18 +0000
Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BN1AFFO11FD008.mail.protection.outlook.com (10.58.52.68) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Tue, 12 Mar 2013 20:12:18 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Tue, 12 Mar 2013 20:11:42 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Richard Barnes <rlb@ipv.sx>, John Bradley <ve7jtb@ve7jtb.com>
Thread-Topic: [jose] RSASSA-PSS signature
Thread-Index: Ac4fUsSatNxE3pBSSnqP5xo0kQPdBQABHnOAAADa5gAAAKOmYA==
Date: Tue, 12 Mar 2013 20:11:41 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394367500130@TK5EX14MBXC283.redmond.corp.microsoft.com>
References: <8B4C063947CD794BB6FF90C78BAE9B321EFC0A36@IMCMBX04.MITRE.ORG> <9E337D95-53AD-431D-A053-76F1F5EF7FAA@ve7jtb.com> <CAL02cgQS6pRjFJGdnin_hToTNGak2XDmb-6j3vVGUi1eZb_1Cg@mail.gmail.com>
In-Reply-To: <CAL02cgQS6pRjFJGdnin_hToTNGak2XDmb-6j3vVGUi1eZb_1Cg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.36]
Content-Type: multipart/mixed; boundary="_004_4E1F6AAD24975D4BA5B168042967394367500130TK5EX14MBXC283r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(24454001)(377454001)(199002)(189002)(377424002)(16236675001)(33656001)(47976001)(55846006)(51856001)(47446002)(54316002)(63696002)(50986001)(49866001)(59766001)(79102001)(65816001)(77982001)(54356001)(31966008)(80022001)(16406001)(69226001)(562884003)(76482001)(46102001)(66066001)(20776003)(5343655001)(15202345001)(5343635001)(74662001)(74502001)(56776001)(53806001)(47736001)(4396001)(512954001)(56816002); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB021; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 078310077C
Cc: "Peck, Michael A" <mpeck@mitre.org>, "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] RSASSA-PSS signature
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Mar 2013 20:12:23 -0000

Your statement that there are no MTI algorithms is actually incorrect.  The current JWA draft specifies REQUIRED (and RECOMMENED and OPTIONAL) algorithms, and indeed, as currently chartered, we are required to define the set of MTI algorithms.

The spreadsheet characterizing platform support for possible algorithms that John referred to is attached.  As you can see, RSA PKCS1-v1_5 is the only ubiquitously implemented asymmetric encryption algorithm.

                                                            -- Mike

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Tuesday, March 12, 2013 12:49 PM
To: John Bradley
Cc: Peck, Michael A; jose@ietf.org
Subject: Re: [jose] RSASSA-PSS signature

Since we are not putting requirements on algorithms (i.e., there is no MTI), there's no harm to having PSS in the algorithms list.  Only benefit!
--Richard


On Tue, Mar 12, 2013 at 3:24 PM, John Bradley <ve7jtb@ve7jtb.com<mailto:ve7jtb@ve7jtb.com>> wrote:
This has had a fair amount of discussion.   While I think almost everyone would prefer PSS, many implementations are going to be in scripting languages where the underlying libraries only support PKCS1-v1_5.

We did a survey of platforms to evaluate if we could move to PSS and the result lead us not to make PSS as the MTI.  In think that was reported out at the Atlanta IETF meeting.
Nat may be able to forward that to you, I don't have it handy.

If we were talking about starting from scratch and not building on existing platforms likely the answer would have been different.

The algorithms are extensible so PSS can be added.   The other consideration is that many of the people who care will be using ECESA signatures anyway.

John B.

On 2013-03-12, at 2:52 PM, "Peck, Michael A" <mpeck@mitre.org<mailto:mpeck@mitre.org>> wrote:

draft-ietf-jose-json-web-algorithms-08 includes RSASSA-PKCS1-v1_5 signatures but not RSASSA-PSS.

The Security Considerations states:
   While Section 8 of RFC 3447 [RFC3447] explicitly calls for people not
   to adopt RSASSA-PKCS1 for new applications and instead requests that
   people transition to RSASSA-PSS, this specification does include
   RSASSA-PKCS1, for interoperability reasons, because it commonly
   implemented.

Shouldn't RSASSA-PSS at least be included as an option?
I'm also not sure if I fully understand the interoperability concerns.  JWS is a new specification, so it makes sense to me to use whatever algorithms are currently considered best practice, without need to worry about backwards compatibility?

Mike

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


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