JDK-8190180 : Add support for RSASSA-PSS Signature algorithm
  • Type: CSR
  • Component: security-libs
  • Sub-Component: java.security
  • Priority: P3
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 11
  • Submitted: 2017-10-25
  • Updated: 2020-04-22
  • Resolved: 2018-05-11
Related Reports
CSR :  
JDK-8146293 - Add support for RSASSA-PSS Signature algorithm
Relates :  
JDK-8243338 - RSSSSA-PSS keys generated from similar KeySpec don't match
Description
Summary
-------

Update existing security classes and "Java Security Standard Algorithm Names" (see https://docs.oracle.com/javase/10/docs/specs/security/standard-names.html) with PKCS#1 "RSA Cryptography Specifications" version 2.2 (RFC 8017) which obsoletes version 2.1 (RFC 3447)

Problem
-------
PKCS#1 v2.2 (RFC 8017) clarifies some ASN.1 data structures and adds new algorithms. Existing JDK security APIs and crypto providers support most but not all algorithms in PKCS#1 v2.1 and need to be updated to support PKCS#1 v2.2.


Solution
--------
 - Update all PKCS#1 v2.1 references with the PKCS#1 v2.2 standard and its ASN.1 syntax
 - Enhance existing RSA-related classes for supporting RSASSA-PSS keys which may contain parameters
 - Add RSASSA-PSS (Probabilistic Signature Scheme) implementation support to SunRsaSign provider
 - Add the support of SHA-512/224 and SHA-512/256 digests to the
   OAEPPadding impl of RSA Cipher implementation in SunJCE provider
 - Update the standard name documentation with RSASSA-PSS

Specification
-------------
Please see the attached "webrev8190180.zip" file which contains changes on all public classes and interfaces.
Comments
Moving to Approved. Some additional comments for consideration: In RSAKeyGenParameterSpec, I recommend two wording changes: Instead of 58 /** 59 * Constructs a new {@code RSAKeyGenParameterSpec} object from the 60 * given keysize, public-exponent value, and no key parameters. 61 * use 58 /** 59 * Constructs a new {@code RSAKeyGenParameterSpec} object from the 60 * given keysize, public-exponent value, and null key parameters. 61 * and instead of 74 * @param publicExponent the public exponent 75 * @param keyParams the key parameters 76 * @since 11 77 */ use 74 * @param publicExponent the public exponent 75 * @param keyParams the key parameters, may be null 76 * @since 11 77 */ This makes the null handling of the new component more explicit. This doesn't require any additional editing of the CSR. In RSAMultiPrimePrivateCrtKeySpec, if you are editing javadoc which uses "@exception", please change the tag to "@throws". Code review comment for RSAMultiPrimePrivateCrtKeySpec Note that + Objects.requireNonNull(publicExponent, + "the publicExponent parameter must be non-null"); ... this.publicExponent = publicExponent; could be equivalently written as this.publicExponent = Objects.requireNonNull(publicExponent, "the publicExponent parameter must be non-null");
11-05-2018
PS I would not expect Optional to be used in this API given the nature of existing security libs APIs, but it would be a reasonable design to consider for new code.
08-05-2018
Thanks for the review comments, I will apply your two code review comments accordingly. As for using Optional, I will run it through with my peer and see what they think.
07-05-2018
A few intermediate comments while continuing to review the spec: Note that RSAKey.java could have default AlgorithmParameterSpec getParams() return an Optional<AlgorithmParameterSpec> instead of using a null to indicate no parameter spec information. However, if I'm not mistaken that would be a new API usage precedent for these APIs. Two code review comments: In PSSParameterSpec.java 109 // disallowed 110 private PSSParameterSpec() { 111 } 112 a stronger form of this is to have the private constructor unconditionally throw and exception. In RSAMultiPrimePrivateCrtKeySpec.java, the idiomatic way to write tests like 135 if (modulus == null) { 136 throw new NullPointerException("the modulus parameter must be " + 137 "non-null"); 138 } is now Objects.requireNonNull(modulu, "the modulus parameter must be non-null");
07-05-2018
Sorry, there was some problem with the earlier webrev.zip. Now that has been fixed and webrev has been re-attached.
04-05-2018
The webrev was attached and then removed. Since the detailed spec changes are not being provided, I'm marking this request as pended.
04-05-2018
Setting scope to "SE" since Java SE APIs are involved and indicating a Java API is the kind of interface being updated. Moving to provisional state. Please set a specific fixVersion before the request is finalized for the next round of CSR review.
26-10-2017