Problem Description

There is a lot of generic DSA support throughout the library, but my fast grep shows that the DSA keys are somehow handled only in the GPK, epass2003 and oberthur drivers:

src/pkcs15init/pkcs15-epass2003.c:              case SC_PKCS15_TYPE_PUBKEY_DSA:

• just pubkey template/names -- probably not working

src/pkcs15init/pkcs15-gpk.c:    case SC_PKCS15_TYPE_PRKEY_DSA:
src/pkcs15init/pkcs15-gpk.c:            algo = SC_ALGORITHM_DSA; break;

• this looks almost like complete support

src/pkcs15init/pkcs15-oberthur.c:               case SC_PKCS15_TYPE_PUBKEY_DSA:

• just public keys template/names -- probably not working

src/libopensc/cardctl.h:        SC_CARDCTL_OBERTHUR_KEY_DSA_PUBLIC,
src/libopensc/cardctl.h:        SC_CARDCTL_OBERTHUR_KEY_DSA_PRIVATE,

• unused defines

src/libopensc/card-dnie.c:              case SC_ALGORITHM_DSA:

• just used to say that it is not supported

I think this might work only in the GPK driver to some extent, but that one is unmaintained anyway since 207 or so and planned to be deactivated.

Proposed Resolution

I am all for removing the support for the DSA in libopensc. It is for no use today and is just maintenance burden. It is not even supported by its creator, NIST in latest FIPS 140-3 release after 2023 so. Before submitting a PRs, I just wanted to check if there are some strong voices against doing so.

I am not about slashing all the occurrences of the DSA (I am fine if it can be detected in pkcs11-tool if needed or similar), but the internal handling this key type in libopensc is not useful.