Re: RFR[11] JDK-8146293 "Add Support for RSA-PSS Signature Algorithm as in PKCS#1 v2.2"
The algorithm name decomposer implementation for algorithm restrictions depends on the pattern: with Using the same "encryption" name for signature and PKCS#1 could be easier for applications if there is a need to decompose the algorithms. 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
RFR (+CSR) 8201627: Kerberos sequence number issues
Please take a review of this fix: webrev: http://cr.openjdk.java.net/~weijun/8201627/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8201814 Basically we fix some bugs and introduce a system property so we can interop with everyone. Thanks Max
Re: RFR[11] JDK-8146293 "Add Support for RSA-PSS Signature Algorithm as in PKCS#1 v2.2"
On 4/18/18 12:52 PM, Xuelei Fan wrote: The algorithm name decomposer implementation for algorithm restrictions depends on the pattern: with 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 ... --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
Re: RFR[11] JDK-8146293 "Add Support for RSA-PSS Signature Algorithm as in PKCS#1 v2.2"
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: with 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
about JDK-8186628
Hi, We are hitting the scalability problem of the SSL session cache in production that JDK-8186628 is addressing. I see that JDK-8186628 has not been updated since Nov'17, so I just wanted to get information about what the current plans are regarding that issue. Thanks, Nezih
RFR CSR 8201906: Use Mozilla Public Suffix List
Please take a review at https://bugs.openjdk.java.net/browse/JDK-8201906 OpenJDK will switch from a home-grown list to Mozilla PSL. This is a behavior change, therefore a CSR. Thanks Max
