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

Xuelei Fan xuelei.fan at oracle.com
Wed Apr 18 18:36:45 UTC 2018

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:

      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. 


> --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