Sorry, it's been a busy day on something else and I haven't looked at your
webrev.01 yet. Will look at it tomorrow.
> On Apr 30, 2020, at 8:15 AM, Valerie Peng <valerie.p...@oracle.com> wrote:
>
>
> 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)
Since ARCFOUR is the standard name, does it make sense to rewrite the OidString
to
ARCFOUR("1.2.840.113549.3.4", "RC4"),
--Max
>
> 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
>>>>
