RFR(S): 8224729: sun/security/provider/certpath/ldap/LDAPCertStoreImpl.java can't handle forward slash characters in Certificate Issuer Names

[Langer, Christoph]

Hi Sean,

ok, I see, you're fully correct. So I hereby withdraw my fix proposal.

As for the exclusion of the test: I have requested it this morning anyway: https://mail.openjdk.java.net/pipermail/security-dev/2019-May/019966.html. So I would assume that you ask Actalis to reissue the certificates anyway and then eventually resolve 8202651 with a good certificate?

As for Bug JDK-8224729: Shall I just close the ticket, dropping a comment about the ignorance of the author or shall I repurpose it to do the other cleanups in LDAPCertStoreImpl.java that I suggested? Don't know if these are appreciated... what do you think?

Best regards
Christoph


> -----Original Message-----
> From: Sean Mullan <sean.mullan at oracle.com>
> Sent: Freitag, 24. Mai 2019 14:02
> To: Langer, Christoph <christoph.langer at sap.com>; security-dev <security-
> dev at openjdk.java.net>
> Subject: Re: RFR(S): 8224729:
> sun/security/provider/certpath/ldap/LDAPCertStoreImpl.java can't handle
> forward slash characters in Certificate Issuer Names
> 
> Hi Christoph,
> 
> I don't think this is the right fix. The LDAP URL in the Certificate is
> incorrect and the forward slash should be escaped. If we start to make
> workarounds in the code to accept certificates that are not properly
> encoded, it becomes a slipperly slope. I base my rationale on the
> following RFCs:
> 
> 1. https://tools.ietf.org/html/rfc5280#section-4.2.1.13
> 
> When the LDAP URI scheme [RFC4516] is
> used, the URI MUST include a <dn> field containing the distinguished
> name of the entry holding the CRL, MUST include a single <attrdesc>
> that contains an appropriate attribute description for the attribute
> that holds the CRL [RFC4523], and SHOULD include a <host>
> (e.g., <ldap://ldap.example.com/cn=example%20CA,dc=example,dc=com?
> certificateRevocationList;binary>).
> 
> 2. https://tools.ietf.org/html/rfc4516#section-2
> 
> The <dn> is an LDAP Distinguished Name using the string format
> described in [RFC4514].  It identifies the base object of the LDAP
> search or the target of a non-search operation.
> 
> 3. https://tools.ietf.org/html/rfc4514#section-2.4
> 
> If that UTF-8-encoded Unicode
> string does not have any of the following characters that need
> escaping, then that string can be used as the string representation
> of the value.
> 
> ...
> 
>    - one of the characters '"', '+', ',', ';', '<', '>',  or '\'
>      (U+0022, U+002B, U+002C, U+003B, U+003C, U+003E, or U+005C,
>      respectively);
> 
> So, I think the proper way to handle this is to contact the CA and
> inform that the certificate does not comply with RFC 5280 and should be
> re-issued. Rajan or I can take care of that and get back to you. For
> now, if this is blocking your testing, I suggest putting the test on the
> ProblemList.
> 
> Thanks,
> Sean
> 
> On 5/24/19 5:11 AM, Langer, Christoph wrote:
> > Hi,
> >
> > please review this fix for an issue that I've discovered when working
> > with test
> >
> security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.ja
> va.
> >
> > It fails when the test tries to do the CRL verification of the
> > certificate. It has issues in the LDAP implementation because of the
> > certificate's name "cn=Actalis Authentication Root CA,o=Actalis
> > S.p.A./03358520967,c=IT". The name contains a forward slash which is at
> > the same time a compound separator in javax.naming/LDAP. So it needs
> > some escaping.
> >
> > I also cleaned up some debugging code and removed/commented out
> unused
> > fields and methods.
> >
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8224729.0/
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8224729
> >
> > Thanks
> >
> > Christoph
> >