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

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)

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.

 - 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

Please see the attached "webrev8190180.zip" file which contains changes on all public classes and interfaces.
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");

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.

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.

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");

Sorry, there was some problem with the earlier webrev.zip. Now that has been fixed and webrev has been re-attached.

The webrev was attached and then removed. Since the detailed spec changes are not being provided, I'm marking this request as pended.

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.