Re: [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.w...@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.p...@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