RFR: 8284553: Deprecate the DEFAULT static field of OAEPParameterSpec

[Valerie Peng]

On Tue, 12 Apr 2022 01:27:35 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> This trivial change is to deprecate the DEFAULT static field of OAEPParameterSpec class. Wordings are mostly the same as the previous PSSParameterSpec deprecation change. Rest are just minor code re-factoring.
> 
> The CSR will be filed once review is somewhat finished.
> 
> Thanks,
> Valerie

> _Mailing list message from [Michael StJohns](mailto:mstjohns at comcast.net) on [security-dev](mailto:security-dev at mail.openjdk.java.net):_
> 
> On 4/11/2022 9:34 PM, Valerie Peng wrote:
> 
> Hi Valerie -
> 
> I think deprecating DEFAULT? is wrong.? RFC8017 still has this definition:
> 
> > RSAES-OAEP-params ::= SEQUENCE {
> > hashAlgorithm      [0] HashAlgorithm     DEFAULT sha1,
> > maskGenAlgorithm   [1] MaskGenAlgorithm  DEFAULT mgf1SHA1,
> > pSourceAlgorithm   [2] PSourceAlgorithm  DEFAULT pSpecifiedEmpty
> > }
> 
> and DEFAULT is what you should be getting if you see an empty sequence in the param field.? It's DEFAULT in ASN1 terms, not DEFAULT in terms of what you should use going forward? to create signatures, and the ASN1 DEFAULT won't change.
> 
> In any event, I can't find where RFC8017 says anything about deprecating the defaults.? AFAICT, although there's general guidance to go away from SHA1,? the math suggests that SHA1 is still sufficient for OAEP,? and there's no guidance specific to OAEP's use of SHA1 that I can find other than the requirement in NIST SP800-56B rev 2 to use "Approved Hash Functions" for OAEP. If there's a section in 8017 that you're looking at for this guidance that I missed, you may want to update your comment to point to it.
> 
> Take care - Mike
> 
> -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20220411/aaa5d423/attachment.htm>

Hi Mike,
Thanks for the comment/feedback. Deprecating the static field in javadoc does not mean we are changing its parameters with something other than those in RFC 8017. Providers can and should still follow the default ASN.1 values when the DER encoding omit the particular field(s). Besides what Sean mentioned already, this deprecation is an effort to moving toward the "explicitly specify what you want to use" direction. Hope this clarifies thing up?
I like the suggestion for using a more specific link and will change it to point to the particular section. 

Regards,
Valerie

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

PR: https://git.openjdk.java.net/jdk/pull/8191