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

[Bradford Wetmore]

I'm fine with #1.

So for Signature, it will only be:

     map.put("Signature.RSA-PSS", "sun.security.rsa.RSAPSSSignature");

Right?

Brad



On 4/27/2018 6:31 PM, Jamil Nimeh wrote:
> Same here.  It is more recognizable/colloquial than #2 and it looks 
> better with the hyphen vs. #4.
> 
> --Jamil
> 
> 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
>>>
>