Hi Sean(s), Tony, I have created the bug https://bugs.openjdk.java.net/browse/JDK-8184673 and posted a change to revert the sigAlgName check. You had indicated that it should be ok to do this for JDK9 and 10 as well, so no behavioral change has to be documented.
If you give the ok, I would push it to JDK10 and I can also do the downport to jdk8u as well as jdk9u once it has opened. All the other backports you'll have to do yourself, e.g. for the Oracle JDKs and/or <8 and the upcoming update releases. Thanks & Best regards Christoph > -----Original Message----- > From: Seán Coffey [mailto:sean.cof...@oracle.com] > Sent: Freitag, 14. Juli 2017 12:17 > To: Anthony Scarpino <anthony.scarp...@oracle.com>; Sean Mullan > <sean.mul...@oracle.com>; Langer, Christoph <christoph.lan...@sap.com> > Cc: OpenJDK Security <security-dev@openjdk.java.net> > Subject: Re: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd > party JCE provider > > Tony, > > I think we should log a JDK 8u bug for this issue if one doesn't already > exist. If the buggy SigAlgName was allowed in 8u updates already, then > it should be continued to be allowed for compatibility reasons IMO. > There might be time to revert that change in 8u152. > > For 9, then maybe we can document the minor behavioural change that' > been introduced. > > Regards, > Sean. > > On 14/07/17 05:25, Anthony Scarpino wrote: > > On 07/12/2017 07:45 AM, Sean Mullan wrote: > >> On 7/11/17 3:10 PM, Langer, Christoph wrote: > > > >>> In any case, from what you are saying, I take that I can safely > >>> patch our JDK distribution with this change without doing a bad > >>> thing to security in general, wouldn't you agree? > >> > >> Yes, I agree. > >> > >> Also, note that you can probably also workaround this issue by adding > >> a specific "SHA1/RSA" constraint to the > >> jdk.certpath.disabledAlgorithms security property. > >> > >> --Sean > > > > The problem cannot be resolved by jdk.certpath.disabledAlgorithms. > > Without using X509CertImpl, the non-standard "SHA1/RSA" is not > > converted to "SHA1withRSA" The failing call is in the > > SSLAlgorithConstraints.permit() checks by matching the algorithm name > > with a list of standard supported algorithm names, and therefore fails. > > > > Tony > >
