Re: [jose] RSASSA-PSS signature

John Bradley <ve7jtb@ve7jtb.com> Tue, 12 March 2013 22:21 UTC

Return-Path: <ve7jtb@ve7jtb.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 D95CE11E812D for <jose@ietfa.amsl.com>; Tue, 12 Mar 2013 15:21:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.974
X-Spam-Level:
X-Spam-Status: No, score=-2.974 tagged_above=-999 required=5 tests=[AWL=0.624, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsq9gWl8jXSc for <jose@ietfa.amsl.com>; Tue, 12 Mar 2013 15:21:02 -0700 (PDT)
Received: from mail-gh0-f169.google.com (mail-gh0-f169.google.com [209.85.160.169]) by ietfa.amsl.com (Postfix) with ESMTP id A009A11E8110 for <jose@ietf.org>; Tue, 12 Mar 2013 15:21:02 -0700 (PDT)
Received: by mail-gh0-f169.google.com with SMTP id r18so81500ghr.28 for <jose@ietf.org>; Tue, 12 Mar 2013 15:21:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=SdJ9n8BgmJgENH7ijsw/Zf2kG43QS9rtvb2bY7f9s9E=; b=a9LWHC9gp0wdEnc/e0GAzEvr27bwIVX00+WqszDAj+wWiMzCy8El7oinBsk0FU+WEn ULuu8qm+spfs2Cx61kfWURVoQXLQHtXV2i1Pk+AvXpbigm4uAoX93ydE53MzBNqXH1xT hbZ5DVDTYDQ5Rk5NvEhz901x5R12hTwRzgKmsqomtOqJpdICvffvpCbETmJml398csgM ZwGkZ4+QkFJi8ScABN/FYLrJoID4gI4d5QICwKHYBRXNee7fNM+v+g84ERg+FJhxOB4W 8dqqFXuxBFBE6uJLG53qpKCXaCbqvYseFTITU45l/PbMM4Kam7kOFHF7iZv0iIABzQaD yVzA==
X-Received: by 10.236.153.131 with SMTP id f3mr13572033yhk.145.1363126861632; Tue, 12 Mar 2013 15:21:01 -0700 (PDT)
Received: from [192.168.11.16] (ip-64-134-186-130.public.wayport.net. [64.134.186.130]) by mx.google.com with ESMTPS id s3sm26479000yhm.10.2013.03.12.15.20.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Mar 2013 15:20:59 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_875E8D7E-6889-44B7-B438-A35460763411"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <8B4C063947CD794BB6FF90C78BAE9B321EFC0B9D@IMCMBX04.MITRE.ORG>
Date: Tue, 12 Mar 2013 18:20:44 -0400
Message-Id: <636E709D-6919-4D18-BE76-3FC34BB3CC6C@ve7jtb.com>
References: <8B4C063947CD794BB6FF90C78BAE9B321EFC0A36@IMCMBX04.MITRE.ORG> <9E337D95-53AD-431D-A053-76F1F5EF7FAA@ve7jtb.com> <CAL02cgQS6pRjFJGdnin_hToTNGak2XDmb-6j3vVGUi1eZb_1Cg@mail.gmail.com> <4E1F6AAD24975D4BA5B168042967394367500130@TK5EX14MBXC283.redmond.corp.microsoft.com> <8B4C063947CD794BB6FF90C78BAE9B321EFC0B9D@IMCMBX04.MITRE.ORG>
To: "Peck, Michael A" <mpeck@mitre.org>
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQmvYv/9H90s5f7kChPTHPprvU+gm+04yL+zwrVD1I5M+DAPnk8YbZHRpWH3i/1yCHd5o9ec
Cc: Richard Barnes <rlb@ipv.sx>, Mike Jones <Michael.Jones@microsoft.com>, "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 22:21:04 -0000

RSA PKCS1-v1.5 is used for both signing and encryption as you are aware it is an encryption/padding alg that is used with a hash function for signature.

The same argument you are making can be used to include RSA-OAEP.

One of the reasons PKCS1 v1.5 padding is so popular is that it can be used to wrap both a key and a hash where the alternative needs to padding als and to be secure two keys.
I agree that it would be better in a perfect world.

Nothing stops additional algorithms being defined.   We have people using the current padding who had strong opinions on that.  
I have yet to see anyone want PSS/OAEP strongly other than as a matter of principal (I have been one of them).

If you feel strongly put forward a use case and propose adding them.

John B.


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

> My original message was not about encryption algorithms, it was about the RSASSA-PSS signature algorithm, which is not in JWA at all (I also don’t see it listed in Mike’s spreadsheet). 
>  
> If you’d like to bring up encryption algorithms too, RFC 3447 states:
>    Two encryption schemes are specified in this document: RSAES-OAEP and
>    RSAES-PKCS1-v1_5.  RSAES-OAEP is recommended for new applications;
>    RSAES-PKCS1-v1_5 is included only for compatibility with existing
>    applications, and is not recommended for new applications.
>  
> 10 years later, it may be appropriate to start encouraging movement away from RSAES-PKCS1-v1_5 rather than further encouraging its use.
> Should the CFRG be asked for an opinion?
>  
> Mike
>  
> From: Mike Jones [mailto:Michael.Jones@microsoft.com] 
> Sent: Tuesday, March 12, 2013 4:12 PM
> To: Richard Barnes; John Bradley
> Cc: Peck, Michael A; jose@ietf.org
> Subject: RE: [jose] RSASSA-PSS signature
>  
> 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> 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> 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
> https://www.ietf.org/mailman/listinfo/jose
>  
> 
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>