Re: [jose] RSASSA-PSS signature

[Brian Campbell <[e-mail]>]

RSA-OAEP is already included, no?
http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08#section-4.1But
it is OPTIONAL while RSAES-PKCS1-V1_5 is REQUIRED. Wasn't that what
was
behind the statement/question about starting to encourage movement away
from RSAES-PKCS1-v1_5 rather than encouraging its use? Or I did I miss the
point there?





On Tue, Mar 12, 2013 at 6:20 PM, John Bradley <[e-mail]> wrote:

> 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" <[e-mail]> 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:[e-mail]]
> *Sent:* Tuesday, March 12, 2013 4:12 PM
> *To:* Richard Barnes; John Bradley
> *Cc:* Peck, Michael A; [e-mail]
> *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:* [e-mail] [mailto:[e-mail]<[e-mail]>
> ] *On Behalf Of *Richard Barnes
> *Sent:* Tuesday, March 12, 2013 12:49 PM
> *To:* John Bradley
> *Cc:* Peck, Michael A; [e-mail]
> *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 <[e-mail]> 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" <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose****
>
> ** **
>
>
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose****
>
>
>
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
>
>