[15] RFR JDK-8242151 Improve OID mapping and reuse among JDK security providers for aliases registration

[Valerie Peng]

If you look at the original SunJCE impl, it also did not register oid 
for RC4 cipher. So, that's why I didn't include RC4 oid in 
SecurityProviderConstants in the aliases for RC4.

If I recall correctly, "RC4" is the algorithm name, however, due to some 
patent(?) concern, non-RSA vendors register their impl under "ARCFOUR" 
and set "RC4" to be the alias. So, that's the convention that I continue 
to use, i.e. use "ARCFOUR" as the standard name and "RC4" as the alias.

I can add the oid as the RC4 alias for completeness sake. (Will update 
in webrev.02)

Thanks,
Valerie
On 4/28/2020 2:39 AM, Weijun Wang wrote:
> I found two algorithm names in a very twisted relation, in SecurityProviderConstants.java:
>
>          store("ARCFOUR", "RC4");
>
> and in OidString.java:
>
>      RC4("1.2.840.113549.3.4", "ARCFOUR")
>
> So each is the other's alias, and because of this, Cipher.ARCFOUR does not have OID aliases.
>
> I can see in https://download.java.net/java/early_access/jdk15/docs/specs/security/standard-names.html that both ARCFOUR and RC4 are standard names. In my understanding, this means both must be supported and it looks like some kind of "required" alias. Is this the reason we have to define them in this way?
>
> Thanks,
> Max
>
>
>> On Apr 28, 2020, at 4:53 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>
>> Where is the following OID used
>>
>>       RSAEncryption("1.2.840.113549.1.1.1", "RSA"), // in RSA Cipher
>>
>> I only found in RSAUtil.java:
>>
>>                 case RSA:
>>                     oid = AlgorithmId.RSAEncryption_oid;
>>                     break;
>>
>> What if we do not give it a different stdName? Or, should we make it an alias in SunJCE for Cipher.RSA?
>>
>> --Max
>>
>>
>>> On Apr 24, 2020, at 7:11 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
>>>
>>> Hi Max,
>>>
>>> Would you have time to review this change? The current webrev attempts to cover all security classes where hard-coded oid strings and consolidate these known oid string values into a single enum type. The changes are quite extensive, I can trim back and only cover the provider algorithm oids if you prefer. There are pros and cons for both approach.
>>>
>>> I know that the naming convention is to use all upper case for enum constants, but choose to use the same naming convention as standard names to simplify the code. SecurityProviderConstants class defines the common mappings which are general to providers. Provider-specific alias mappings are handled in specific provider class, e.g. SunJSSE class.
>>>
>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8242151
>>>
>>> Webrev: http://cr.openjdk.java.net/~valeriep/8242151/webrev.00/
>>>
>>> Mach5 runs clean.
>>>
>>> Valerie
>>>