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

[Anthony Scarpino]

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
>