RFR: 8302017: Allocate BadPaddingException only if it will be thrown [v3]

[Xue-Lei Andrew Fan]

On Mon, 24 Jul 2023 19:58:34 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/rsa/RSASignature.java line 227:
>> 
>>> 225:                 byte[] padded2 = padding.pad(encoded2);
>>> 226:                 return MessageDigest.isEqual(padded2, decrypted);
>>> 227:             }
>> 
>> I had a check of the specification (Section A.2.4 of RFC 8017), and the [update](https://github.com/openjdk/jdk/pull/8365) and the [JBS entry](https://bugs.openjdk.org/browse/JDK-8285404) that added the comment "some vendors might omit the NULL params".
>> 
>> Per section A.2.4 of RFC 8017, it is said "For each OID, the parameters field associated with this OID in a value of type  AlgorithmIdentifier SHALL have a value of type NULL."
>> 
>> Per the key words specification, RFC 2119, "SHALL" is the same as MUST which  "mean that the definition is an absolute requirement of the specification."
>> 
>> In the bug description of bug JDK-8285404, there is a section "*Update*: We think it's possible that there might be signers omitting the NULL params in the digest algorithm identifier. "
>> 
>> For this case, if the signers omitting the NULL params, does it means the signer does not follow the specification and should be rejected?  @wangweij could you recall if there is a real case that omits the NULL params in practice?
>
> Max is on vacation and may not see your question for a while...
> IIRC, the inconsistency (NULL vs omission) goes way back. As time goes on, this may no longer be an issue as spec is clarified and vendors update their implementation.

I checked back the specification back to RFC 2437, released on October 1998, which requires to encode NULL parameters as well.  As the update to keep the consistency is not trivial, I may just remove it and see if it could be a real problem in practice.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14839#discussion_r1273015418