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

Sean Mullan sean.mullan at oracle.com
Wed Aug 26 12:02:57 UTC 2020

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().


> 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

More information about the security-dev mailing list