cc @golang/security

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".

Hi Filippo :-D

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

Thanks again for your time.