You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are developing a program targeting multiple old platforms involving hardware smartcard and only PKCS#1 V1.5 Signature Scheme is supported on the client platform. We use only the signing part so it should hold for a while. We need to specify SignatureSchemes on the server side but it seems to be tricky. We can only implement it by specifying it to internal structures of each Certificate within the CertPool and it's ugly and dirty.
We assume it should be a common issue when it comes to old platforms. Please add official support so we can simply use tls.Config to specify it.
Thank you all and the golang, the best lang ever.
The text was updated successfully, but these errors were encountered:
Hello! If the client only supports that signature scheme, shouldn't it only advertise support for it in the Client Hello, and let negotiation take care of it?
Anyway, this is not a common issue (it's the first time I hear of it) and we try to reduce the range of configurable settings, rather than increase them, so it's unlikely we'll add another field to Config for it.
As you found, it should be possible to control this behavior with Certificate.SupportedSignatureAlgorithms. We are ok with making "common things easy, and uncommon things possible".
Thanks for your rapid reply. You are absolutely right and it should have been informed in the Client Hello. But when it comes to browsers on some old platforms and things like smartcard CSP/CNG, it is nearly impossible to handle it esaily by client programs because they are not open sourced. So we have to use server side to mandate it. And such scenarios are more common in business using smartcard authentication because of the involvement of CSP/CNG/driver.
And I personally think the addition would also have some cryptographic advantages. As you know, PKCS#1 v1.5 padding scheme holds its security on signing till these days and maintains a great compatibility on some old smartcards while PSS has a tighter security proof. I believe it would be better to allow developers to choose such trade-off between security and compatibility like cipher suite field does. And by leaving the default value secure should be enough to keep the use of Config simple and robust.
Considering the wide use of the golang in different industries, the advantages of adding such field should outweigh the disadvantages.
I could make the PR of this change but I would like to make sure the community won't hate it :-D
It's a little different from the Issue 43549.
We are developing a program targeting multiple old platforms involving hardware smartcard and only PKCS#1 V1.5 Signature Scheme is supported on the client platform. We use only the signing part so it should hold for a while. We need to specify SignatureSchemes on the server side but it seems to be tricky. We can only implement it by specifying it to internal structures of each Certificate within the CertPool and it's ugly and dirty.
We assume it should be a common issue when it comes to old platforms. Please add official support so we can simply use tls.Config to specify it.
Thank you all and the golang, the best lang ever.
The text was updated successfully, but these errors were encountered: