[10] RFR: 8182143: SHA224-based signature algorithms are not enabled for TLSv12 on Windows
Artem Smotrakov
artem.smotrakov at oracle.com
Fri Jun 16 17:30:45 UTC 2017
Hi Xuelei,
Please see inline.
On 06/15/2017 07:32 PM, Xuelei Fan wrote:
> Hi Artem,
>
> If the key is generated in MSCAPI, the signature algorithm implemented in other provider cannot be actually used.
Yes, that's what I meant by key implementation incompatibility. Here is
an example
https://bugs.openjdk.java.net/browse/JDK-8176183
We updated the test to use the same provider for key generation and
signatures. I'll file a bug for that.
>
> BTW, we also need to consider the case that only MSCAPI provider is enabled in practice.
Agree. If a provider provides everything what's necessary for a TLS
connection - it should work.
Artem
>
> In general, a signature algorithm is not included in the supported list unless all related providers support the signature algorithm. We're looking for better solution, but not yet have one in hand.
>
> Xuelei
>
>> On Jun 15, 2017, at 6:13 PM, Artem Smotrakov <artem.smotrakov at oracle.com> wrote:
>>
>> That sounds strange to me. I assume that if an algorithm is provided by a provider on all platforms, then it should work on all platforms no matter what. I am not sure that I really understand the problem, but probably it's about some problems that may occur if multiple providers are used together when for a TLS connection. I may guess that the problem may be in incompatibility of key implementations for different providers. If so, this looks like an issue to me. Please correct me if I am wrong.
>>
>> Probably there may be some specific case which fails, but SignatureAlgorithms.java test works fine now, and seems like SHA224 can be successfully used for establishing a connection.
>>
>> I am okay to back out the fix, but it would be good to have a testcase which shows the problem why the fix should be backed out. Then, we can work on a solution for that.
>>
>> Artem
>>
>>
>>> On 06/15/2017 04:37 PM, Xuelei Fan wrote:
>>> Hi Bernd,
>>>
>>> Thanks for the correction. I really missed the point that there are issues to enabled SHA-224 for SunMSCAPI provider.
>>>
>>>> On 6/15/2017 4:06 PM, Bernd Eckenfels wrote:
>>>> Hello,
>>>>
>>>> If I recall correctly the idea of disabling those algorithms if SunMSCAPI IS(!) present was to avoid agreeing on a Signature algorithm which could not be supported by RSA offloaded keys inside CryptoAPI.
>>>>
>>>> Having said that the suggested ciphers might need to be made dependent on the capabilities of the Signature provider for a given key type (especially if it is a key handle only).
>>>>
>>> Agreed. Besides, we may check the availability of each signature and hash algorithms, rather than hard-coded them. I filed a new bug for the tracking:
>>> https://bugs.openjdk.java.net/browse/JDK-8182318
>>>
>>> Thanks & Regards,
>>> Xuelei
>>>
>>>> Has this changed and the signatures are supported now by MSCapi?
>>>>
>>>> Gruss
>>>> Bernd
>>>> --
>>>> http://bernd.eckenfels.net
>>>> ------------------------------------------------------------------------
>>>> *From:* security-dev <security-dev-bounces at openjdk.java.net> on behalf of Artem Smotrakov <artem.smotrakov at oracle.com>
>>>> *Sent:* Thursday, June 15, 2017 10:57:00 PM
>>>> *To:* Xuelei Fan; Security Dev OpenJDK
>>>> *Subject:* [10] RFR: 8182143: SHA224-based signature algorithms are not enabled for TLSv12 on Windows
>>>> Hi Xuelei,
>>>>
>>>> Could you please take a look at this patch?
>>>>
>>>> It enables SHA224-based signature algorithms on Windows since they
>>>> should be provided not only by SunMSCAPI provider. Please see details in
>>>> the bug description.
>>>>
>>>> The test works fine on all supported platforms.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8182143
>>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8182143/webrev.00/
>>>>
>>>> Artem
More information about the security-dev
mailing list