[RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd party JCE provider

Anthony Scarpino anthony.scarpino at oracle.com
Thu Jul 13 18:26:40 UTC 2017

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

More information about the security-dev mailing list