When an AlgorithmId object with no parameters is encoded, sometimes we put an ASN.1 NULL there, sometimes we do not emit the parameters field at all. Currently, we maintain a hardcoded list for the latter cases inside JDK. If an OID does not fall into that list, we add a NULL.

Recently defined object identifiers all claim that parameters MUST be absent if there is none. This means every time such an OID is introduced we will need to update the list. It is quite likely that we forget about one of them, especially if the OID is first supported by a 3rd party security provider.

I suggest we inverse the check and maintain a hardcoded list for those OIDs that requires a NULL. According to RFC 8017, all RSA related key and signature algorithms require NULL. MessageDigest algorithms like SHA-1 and SHA-256 are not required (or even recommended) to add a NULL but traditionally vendors add a NULL there. These are the 2 families of OIDs that will be included in the current list.

For all other OIDs, when there is no parameters, we will not encode it at all. This will be a behavior change for those that were not in the current do-not-encode list. Most documents and specifications would either require the parameters to be absent or require an implementation to accept both present and absent parameters. Existing tests have not revealed any interoperability issue.