RFR (16): 8241003: Deprecate "denigrated" java.security.cert APIs that represent DNs as Principal or String objects

[Valerie Peng]

Ok, thanks for the reply.

Valerie

On 8/26/2020 5:02 AM, Sean Mullan wrote:
> On 8/21/20 2:14 PM, Valerie Peng wrote:
>> Is it intentional to use toString() in 
>> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java? 
>> Normally, toString() is kind of loose, not as strict as getName().
>
> In this case I think toString() is ok, since jarsigner is printing 
> information about the certificate.
>
> Also, I wanted the format to be compatible with the previous code just 
> in case some script or something out there is parsing the format and 
> expecting it to be the same. In the JDK implementation, 
> X500Principal.toString calls X500Name.toString().
>
> --Sean
>
>>
>> Valerie
>>
>> On 8/21/2020 11:01 AM, Xuelei Fan wrote:
>>> Looks fine to me.
>>>
>>> Just a trivial format comment.  Some use link for "RFC 2253", some 
>>> do not. It's OK.  And it's good as well if you want to use a uniform 
>>> style.
>>>
>>> Xuelei
>>>
>>> On 8/21/2020 9:24 AM, Sean Mullan wrote:
>>>> Ping ...
>>>>
>>>> On 8/7/20 10:01 AM, Sean Mullan wrote:
>>>>> Please review this change to deprecate the following APIs:
>>>>>
>>>>> java.security.cert.X509Certificate.getIssuerDN()
>>>>> java.security.cert.X509Certificate.getSubjectDN()
>>>>> java.security.cert.X509CRL.getIssuerDN()
>>>>> java.security.cert.X509CertSelector.setIssuer(String)
>>>>> java.security.cert.X509CertSelector.setSubject(String)
>>>>> java.security.cert.X509CertSelector.getIssuerAsString()
>>>>> java.security.cert.X509CertSelector.getSubjectAsString()
>>>>> java.security.cert.X509CRLSelector.addIssuerName(String)
>>>>>
>>>>> These APIs either take or return Distinguished Names as Principal 
>>>>> or String objects which can cause issues due to loss of encoding 
>>>>> information or differences when comparing names across different 
>>>>> Principal implementations. All of them have alternative APIs which 
>>>>> use X500Principal objects instead. They have long had warnings in 
>>>>> the javadoc and have been discouraged from being used. There are 
>>>>> no plans to remove the APIs at this time, as they have been in the 
>>>>> platform for a long time and removing them would be a much higher 
>>>>> compatibility risk.
>>>>>
>>>>> webrev: 
>>>>> https://cr.openjdk.java.net/~mullan/webrevs/8241003/webrev.00/
>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8250970
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8241003
>>>>>
>>>>> --Sean