RFR[11] JDK-8146293 "Add Support for RSA-PSS Signature Algorithm as in PKCS#1 v2.2"

Valerie Peng valerie.peng at oracle.com
Mon Apr 30 18:40:57 UTC 2018


I reordered the names and missed to update some of the description.

#2 and #3 are from 3rd party providers. #1 is what I have in the webrev, 
#4 is just a new alternative in case people may prefer it over #1.

Can you all please re-confirm your preference is?
Thanks!
Valerie

On 4/27/2018 4:51 PM, Sean Mullan wrote:
> My vote is #1.
>
> --Sean
>
> On 4/27/18 7:41 PM, Valerie Peng wrote:
>>
>> I'd also strongly prefer to pick one as standard name for RSA PSS 
>> signature and use it consistently.
>>
>> Here are the possible choices for RSA PSS standard names:
>>
>>  1. RSA-PSS
>>  2. RSASSA-PSS
>>  3. RSA/PSS
>>  4. RSAPSS
>>
>> #1,#2 are from 3rd party provider, #3 is what I have in current 
>> webrev, #4 is just a new alternative in case people may prefer it 
>> over #1.
>>
>> My preference is #1, #2, and #4. My reason for steering away from #3 
>> is due to that "/" is used by Cipher transformation string. Though 
>> Signature algorithm is separate from Cipher transformation, but RSA 
>> can be used for encryption and having that "/" is potentially very 
>> confusing.
>>
>> Comments? Please share your preference soon so I can update the 
>> webrev accordingly...
>>
>> Thanks,
>> Valerie
>>
>> On 4/18/2018 11:36 AM, Xuelei Fan wrote:
>>> On 4/18/2018 11:25 AM, Sean Mullan wrote:
>>>> On 4/18/18 12:52 PM, Xuelei Fan wrote:
>>>>> The algorithm name decomposer implementation for algorithm 
>>>>> restrictions depends on the pattern:
>>>>>     <digest>with<encryption>
>>>>>
>>>>> Using the same "encryption" name for signature and PKCS#1 could be 
>>>>> easier for applications if there is a need  to decompose the 
>>>>> algorithms.
>>>>
>>>> Hmm, so do you mean this is a problem if you specify the signature 
>>>> algorithm as "RSA-PSS" and require that the digest algorithm be 
>>>> specified as a parameter to the API? Or something else? Not sure I 
>>>> understand you but I have a feeling you are raising a good point ...
>>>>
>>> The concern is from the names BC and Andriod used:
>>>
>>>      SHA*withRSA/PSS
>>>      RSASSA-PSS (name from PKCS#1)
>>>
>>> The signature algorithm decomposing SHA*withRSA/PSS and "SHA*" and 
>>> "RSA/PSS".  If the PKCS#1 name use "RSASSA-PSS", it is tricky to map 
>>> "RSA/PSS" to "RSASSA-PSS".  I'm suggesting use a consistent name. 
>>> Either "SHA*withRSA/PSS"/"RSA/PSS" or 
>>> "SHA*withRSASSA-PSS"/"RSASSA-PSS".
>>>
>>> Xuelei
>>>
>>>> --Sean
>>>>
>>>>>
>>>>> Xuelei
>>>>>
>>>>> On 4/16/2018 11:40 AM, Sean Mullan wrote:
>>>>>> On 4/13/18 3:25 PM, Bradford Wetmore wrote:
>>>>>>> SunRsaSignEntries.java
>>>>>>> ----------------------
>>>>>>> 145:  Where did you come up with this convention for your aliases?
>>>>>>>
>>>>>>>      SHA1withRSA-PSS
>>>>>>>
>>>>>>> I see Bouncy Castle[1] and Android[2] are both using:
>>>>>>>
>>>>>>>      SHA*withRSA/PSS
>>>>>>>      RSASSA-PSS (name from PKCS#1)
>>>>>>>
>>>>>>> [1] 
>>>>>>> https://github.com/bcgit/bc-java/blob/master/prov/src/main/java/org/bouncycastle/jcajce/provider/asymmetric/RSA.java 
>>>>>>>
>>>>>>> [2] 
>>>>>>> https://developer.android.com/reference/java/security/Signature.html 
>>>>>>>
>>>>>>>
>>>>>>> but we have neither style.
>>>>>>
>>>>>> Since these standard names have not yet been defined, we don't 
>>>>>> necessarily have to be consistent, but I don't see a good enough 
>>>>>> reason for us to name them differently, so to help with 
>>>>>> compatibility I would go with the names above.
>>>>>>
>>>>>> --Sean
>>




More information about the security-dev mailing list