[erlang-questions] Handshake failure with DHE-DSS cipher suites

[Per Hedeland]

Hi,

For no other reason than the fact that our documentation claims that we
support all the ciphers listed by ssl:cipher_suites(openssl) (users can
select a subset by configuring a list of OpenSSL names), I actually have
a test that tries them individually, and in OTP 20 ssl:ssl_accept()
fails with {error, {tls_alert,"handshake failure"}} for all the DHE-DSS
suites - i.e.

 DHE-DSS-AES256-SHA256
 DHE-DSS-AES128-SHA256
 DHE-DSS-AES256-SHA
 DHE-DSS-AES128-SHA
 DHE-DSS-AES256-GCM-SHA384
 DHE-DSS-AES128-GCM-SHA256

a.k.a.

 {dhe_dss,aes_256_cbc,sha256}
 {dhe_dss,aes_128_cbc,sha256}
 {dhe_dss,aes_256_cbc,sha}
 {dhe_dss,aes_128_cbc,sha}
 {dhe_dss,aes_256_gcm,aead,sha384}
 {dhe_dss,aes_128_gcm,aead,sha256}

After debugging a bit with the first one, I found that the failure was
due to a function_clause error, and that this change made it work:

--- a/lib/public_key/src/public_key.erl
+++ b/lib/public_key/src/public_key.erl
@@ -505,7 +505,9 @@ pkix_sign_types(?'ecdsa-with-SHA256') ->
 pkix_sign_types(?'ecdsa-with-SHA384') ->
     {sha384, ecdsa};
 pkix_sign_types(?'ecdsa-with-SHA512') ->
-    {sha512, ecdsa}.
+    {sha512, ecdsa};
+pkix_sign_types({2,16,840,1,101,3,4,3,2}) ->
+    {sha256, dsa}.

 %%--------------------------------------------------------------------
 -spec sign(binary() | {digest, binary()},

Some googling indicates that the oid-tuple could reasonably be named
'id-dsa-with-sha256', no real surprise there - a bit more surprising is
that the change actually makes *all* of those suites work. Now, I don't
really know what I'm doing here, so: Is this just an omission in the
public_key code and the above a reasonable fix, or is there some
fundamental reason that pkix_sign_types/1 shouldn't handle that oid?
(And if the latter, how can the DHE-DSS suites be made to work without
it?)

The test was run with 'openssl s_client' connecting to 20.3.6 - I can't
easily plug 21.0-rc1 into the test, but it seems at least
public_key:pkix_sign_types/1 is the same there.

Thanks

--Per Hedeland