Subject: [jose] RSASSA-PSS signature

From: "Peck, Michael A" <[email-masked]>
Date: Tue, 12 Mar 2013 18:52:39 +0000

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

---

From: John Bradley <[email-masked]>
Date: Tue, 12 Mar 2013 15:24:41 -0400

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" <[email-masked]> wrote:

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Richard Barnes <[email-masked]>
Date: Tue, 12 Mar 2013 15:49:10 -0400

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 <[email-masked]> 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.
> 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.
>
> 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****
> ** **

---

From: Mike Jones <[email-masked]>
Date: Tue, 12 Mar 2013 20:11:41 +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: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Tuesday, March 12, 2013 12:49 PM
To: John Bradley
Cc: Peck, Michael A; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> 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.

John B.

On 2013-03-12, at 2:52 PM, "Peck, Michael A" <[email-masked]<mailto:[email-masked]>> wrote:

Mike

_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

---

From: Richard Barnes <[email-masked]>
Date: Tue, 12 Mar 2013 16:24:09 -0400

Yes, I know the current JWA says that.  That's a bug.  I just submitted an
issue.  We have discussed this several times in the working group, most
recently in Atlanta, where there was a fair degree of agreement on removing
requirements levels.

--Richard

On Tue, Mar 12, 2013 at 4:11 PM, Mike Jones <[email-masked]>wrote:

>  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:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Richard Barnes
> *Sent:* Tuesday, March 12, 2013 12:49 PM
> *To:* John Bradley
> *Cc:* Peck, Michael A; [email-masked]
> *Subject:* Re: [jose] RSASSA-PSS signature****
>
> ** **
>
> ****
> --Richard****
> On Tue, Mar 12, 2013 at 3:24 PM, John Bradley <[email-masked]> wrote:**
> **
>
> languages where the underlying libraries only support PKCS1-v1_5.****
>
> ** **
>
> at the Atlanta IETF meeting.****
>
> Nat may be able to forward that to you, I don't have it handy.****
>
> ** **
>
> existing platforms likely the answer would have been different.****
>
> ** **
>
> signatures anyway.****
> John B.****
> On 2013-03-12, at 2:52 PM, "Peck, Michael A" <[email-masked]> wrote:****
>
> ** **
>
>  ****
>  ****
>  ****
>  ****
> https://www.ietf.org/mailman/listinfo/jose****
>
>  ** **
>
>
> https://www.ietf.org/mailman/listinfo/jose****
>
> ** **
>

---

From: Mike Jones <[email-masked]>
Date: Tue, 12 Mar 2013 20:29:45 +0000

I obviously defer to the working group on whether it's a bug or not.  I was just trying to have us be clear on what the specs actually say and why.

We should probably try to get a clear decision on whether to change that tomorrow.  Maybe John should incorporate a slide on it into his presentation, since he's already covering all the other open issues?

                                                            Cheers,
                                                            -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Tuesday, March 12, 2013 1:24 PM
To: Mike Jones
Cc: John Bradley; Peck, Michael A; [email-masked]
Subject: Re: [jose] RSASSA-PSS signature

Yes, I know the current JWA says that.  That's a bug.  I just submitted an issue.  We have discussed this several times in the working group, most recently in Atlanta, where there was a fair degree of agreement on removing requirements levels.

--Richard

On Tue, Mar 12, 2013 at 4:11 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
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.

                                                            -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Richard Barnes
Sent: Tuesday, March 12, 2013 12:49 PM
To: John Bradley
Cc: Peck, Michael A; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] RSASSA-PSS signature

John B.

Mike

---

From: John Bradley <[email-masked]>
Date: Tue, 12 Mar 2013 16:43:09 -0400

I have already updated the slides and sent them on to Jim and Karen to include the issue.

The question is given the recent feedback on interoperability, is if IDESG will allow us through with no MTI.

MTI is not mandatory to use as a WG chair once mentioned.   

Is there really a objection to having libraries include the ability to do RSA-PKCS1-v1.5 encryption as a base?

I agree applications determine the algorithms used. 

John B.

On 2013-03-12, at 4:29 PM, Mike Jones <[email-masked]> wrote:

> I obviously defer to the working group on whether it’s a bug or not.  I was just trying to have us be clear on what the specs actually say and why.
>  
> We should probably try to get a clear decision on whether to change that tomorrow.  Maybe John should incorporate a slide on it into his presentation, since he’s already covering all the other open issues?
>  
>                                                             Cheers,
>                                                             -- Mike
>  
> On Tue, Mar 12, 2013 at 4:11 PM, Mike Jones <[email-masked]> wrote:

---

From: "Peck, Michael A" <[email-masked]>
Date: Tue, 12 Mar 2013 21:10:05 +0000

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:[email-masked]]
Sent: Tuesday, March 12, 2013 4:12 PM
To: Richard Barnes; John Bradley
Cc: Peck, Michael A; [email-masked]
Subject: RE: [jose] RSASSA-PSS signature

                                                            -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Tuesday, March 12, 2013 12:49 PM
To: John Bradley
Cc: Peck, Michael A; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] RSASSA-PSS signature

John B.

Mike

---

From: John Bradley <[email-masked]>
Date: Tue, 12 Mar 2013 18:20:44 -0400

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" <[email-masked]> 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:

---

From: Richard Barnes <[email-masked]>
Date: Tue, 12 Mar 2013 18:25:11 -0400

Identifiers are cheap, modern algorithms are good.  Just add them!
--Richard

On Tue, Mar 12, 2013 at 6:20 PM, John Bradley <[email-masked]> 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.
>
> 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.
> Nothing stops additional algorithms being defined.   We have people using
> the current padding who had strong opinions on that.
> 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:[email-masked]]
> *Sent:* Tuesday, March 12, 2013 4:12 PM
> *To:* Richard Barnes; John Bradley
> *Subject:* RE: [jose] RSASSA-PSS signature****
> ** **
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>
> ] *On Behalf Of *Richard Barnes

---

From: John Bradley <[email-masked]>
Date: Tue, 12 Mar 2013 18:47:13 -0400

If only I were King:)

If the workgroup wants them added they get added.   I don't have anything against adding them, other than not wanting to fill up the specs with cruft that will scare away developers.

Is someone saying they want to use OAEP/PSS?    Someone anyone saying they need it would probably be sufficient to get the WG to make the addition.
Honestly my very early draft with Nat had OAEP/PSS as the defaults and we got talked out of that.   

However my argument for OAEP/PSS is academic so real deployer desire is going to be more influential.

John B.

---

From: Brian Campbell <[email-masked]>
Date: Tue, 12 Mar 2013 18:52:58 -0400

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?