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.mul...@oracle.com> > Sent: Freitag, 24. Mai 2019 14:02 > To: Langer, Christoph <christoph.lan...@sap.com>; security-dev <security- > d...@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 > >
