JDK-8206864 : Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized
  • Type: CSR
  • Component: security-libs
  • Sub-Component: java.security
  • Priority: P3
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 11
  • Submitted: 2018-07-06
  • Updated: 2018-07-20
  • Resolved: 2018-07-20
Related Reports
CSR :  
JDK-8206171 - Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized
Description
Summary
-------
Existing javadoc of java.security.Signature.getParameters() specifies that it returns that the parameters used with this signature object. Additionally, it mentions that

 - *null* is returned when the signature algorithm does not use parameters
   and
 
 - parameters containing a combination of default and randomly generated parameter values is returned if this signature requires algorithm parameters but was not initialized with any.


However, for the second item above, if there is no provider-specific default parameters, Signature.getParameters() should return null.

Problem
-------
Please see Summary.

Solution
--------
Update javadoc of java.security.Signature.getParameters() to specify null to be returned if no default parameters are generated. Same update is applied to the javadoc of java.security.SignatureSpi.engineGetParameters() which inherits much of its spec from java.security.Signature.getParameters().

Specification
-------------

1) java.security.Signature.getParameters(): Inline patch included as below:

    @@ -895,18 +895,19 @@
         }
     
         /**
          * Returns the parameters used with this signature object.
          *
    -     * <p>The returned parameters may be the same that were used to initialize
    -     * this signature, or may contain a combination of default and randomly
    -     * generated parameter values used by the underlying signature
    -     * implementation if this signature requires algorithm parameters but
    -     * was not initialized with any.
    +     * <p> If this signature has been previously initialized with parameters
    +     * (by calling the {@code setParameter} method), this method returns
    +     * the same parameters. If this signature has not been initialized with
    +     * parameters, this method may return a combination of default and
    +     * randomly generated parameter values if the underlying
    +     * signature implementation supports it and can successfully generate
    +     * them. Otherwise, {@code null} is returned. 
          *
    -     * @return the parameters used with this signature, or null if this
    -     * signature does not use any parameters.
    +     * @return the parameters used with this signature, or {@code null}
          *
          * @see #setParameter(AlgorithmParameterSpec)
          * @since 1.4
          */
         public final AlgorithmParameters getParameters() {

2)  java.security.SignatureSpi.engineGetParameters(): Inline patch included as below:

    @@ -324,22 +324,22 @@
             throws InvalidAlgorithmParameterException {
                 throw new UnsupportedOperationException();
         }
     
         /**
    -     * <p>This method is overridden by providers to return the
    -     * parameters used with this signature engine, or null
    -     * if this signature engine does not use any parameters.
    +     * <p>This method is overridden by providers to return the parameters
    +     * used with this signature engine.
          *
    -     * <p>The returned parameters may be the same that were used to initialize
    -     * this signature engine, or may contain a combination of default and
    -     * randomly generated parameter values used by the underlying signature
    -     * implementation if this signature engine requires algorithm parameters
    -     * but was not initialized with any.
    +     * <p> If this signature engine has been previously initialized with
    +     * parameters (by calling the {@code setParameter} method), this method
    +     * returns the same parameters. If this signature engine has not been
    +     * initialized with parameters, this method may return a combination of
    +     * default and randomly generated parameter values if the underlying
    +     * signature implementation supports it and can successfully generate
    +     * them. Otherwise, {@code null} is returned. 
          *
    -     * @return the parameters used with this signature engine, or null if this
    -     * signature engine does not use any parameters
    +     * @return the parameters used with this signature engine, or {@code null}
          *
          * @exception UnsupportedOperationException if this method is
          * not overridden by a provider
          * @since 1.4
          */
Comments
Moving to Approved.
20-07-2018
Please change the request's status to "Finalized" when it is ready for the second phase of CSR review.
18-07-2018
For JDK providers, only the new signature impl RSASSA-PSS of SunRsaSign provider throws ProviderException when users have not supplied/initialized the signature with a parameter. Per Joe's feedback, I have changed the compatibility risk to low. I initially put the risk as minimum since other signature algorithms (supported by JDK providers) do not use any signature parameters (null is returned when calling Signature.getParameters()) and it's probably not used much in real-world apps. After some further discussion, we feel it may be better to return null for Signature.getParameters() if no parameters is given. If the signature algorithm requires parameters but the provider does not generate default parameters, it will fail in subsequent calls when the actual operation is performed. Existing javadoc for Signature.sign() and Signature.verify(...) methods state that SignatureException will be thrown if the Signature object is not initialized properly which fit the scenario well. CSR has been updated accordingly.
16-07-2018
Before the request is finalized, please that what "underlying signature implementation may also fail" mean operationally, presumably some exception is thrown. Please clarify if this change is documenting existing behavior or allowing a new failure condition. If it is the latter, than a larger compatibility impact would be warranted. Moving to Provisional.
10-07-2018