Hi Sean, > > So, I guess I would be fine if this could at least be changed for JDKs <= 8 > > for > compatibility reasons. I can understand if for JDK >= 9 we say this is a new > release and the standard algorithm names shall be enforced. Wouldn't that > be a good compromise? > > Yes. In fact I think the most robust solution (even for 9 and later) is > to look at the encoded AlgorithmId in the X.509 certificate to determine > what signature algorithm is being used, and this would eliminate the > compatibility risk with third party providers using non-standard Java > names. This is exactly what X509CertImpl.getSigAlgName() is doing.
OK, I will file a bug and post a change for review. I then suggest to also revert JDK10 and 9 to use X509CertImpl.getSigAlgName() for the time being until some better check to go for the encoded AlgorithmId. Would you be fine with that? > Also, note that you can probably also workaround this issue by adding a > specific "SHA1/RSA" constraint to the jdk.certpath.disabledAlgorithms > security property. Hm, I thought with that property you would only define a negative list of algorithms that are not supported (out of the known ones). But is it possible to specify an unknown algorithm name to whitelist? Thanks Christoph
