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
>>
>
