On 07/12/2017 11:59 PM, Langer, Christoph wrote:
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() forthe time being until some better
check to go for the encoded AlgorithmId. Would you be fine with
that
Looking back at the original code, before any of these changes were put
in, it was always "((X509Certificate)cert).getSigAlgName();". I would
guess I changed this in February to go back to the original method called.
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?
It is a negative list and it has to match the algorithm name. There is
no unknown/catch-all.
Thanks
Christoph
