The documentation URL https://www.agid.gov.it/it/piattaforme/carta-nazionale-servizi leads to
https://www.agid.gov.it/sites/default/files/repository_files/documentazione/filesystemcns_20160610.pdf
last updated 10 giugno(June) 2016
Page 15 has "ATR PDC MI1 Reale - ST/Incard" and list H13 as 0x11. This appears to be your card?

The above URL also leads to:
https://www.agid.gov.it/sites/default/files/repository_files/documentazione_trasparenza/cns_functional_specification_1.1.6_02042011.pdf last revision 2011, and here H13 is 0x10.

pkcs15-itacns.c has many "Fixme:" comments like:

/* This is hard-coded, for the time being. */
int modulus_length = 1024;

I would not make the assumption that H13 == 11 means modulus_length = 2048.

But the public key is both on the card, and in the certificate, (SPKI) and it has the
modulus length.

I would suggest that you rewrite the fix key length changed to get the module_length from the pub key.
itacns_init /*** Certificate and keys. ***/ looks for 4 different certificates and calls itacns_check_and_add_keyset to get the modulus length.

Note the code I sent to to add _sc_card_add_rsa_alg(card, 2048, flags, 0); says the card supports 2048 bit keys in addition to the _sc_card_add_rsa_alg(card, 1024, flags, 0); a few lines above.The 0x11 does not say the certificates, pubkeys and private keys are 2048. Some certificates may have 1024 and others 2048.

Since RSA 1024 is considered unacceptable these days, they may all have 2048. But in a few years 2048 may be considered unacceptable. So for future flexibility, consider getting the modulus length from the certificate which will work in all cases.

Thanks for the suggestions..
I know that the hardcoded values are the worst, but unfortunately I'm not a skilled C++ developer and I knew almost nothing about smartcard until last week 😅.
I'll try to implement everything as you suggest.

pkcs15-itacns.c has: r = sc_pkcs15_read_certificate(p15card, &info, &cert); It reads and parses the cert and returns sc_pkcs15_cert_t with a pointer to the public key as struct sc_pkcs15_pubkey * key;

This diff: untested-card-itacns.c-issue-2370-v-2.txt uses this: *modulus_len = cert->key->u.rsa.modulus.len; It compiles but I can not test it.

See if this works or is a good starting point. It should work for any card because the certificate and key are provided by the gov and should always match.

I should also point out that OpenSC had added code to get the extensions for keyUsage without requiring OpenSSL. So the code around the call to sc_pkcs15_read_certificate could be rewritten too.

*modulus_len = cert->key->u.rsa.modulus.len; is in bytes should be:
*modulus_len = cert->key->u.rsa.modulus.len * 8;

Looks good to me.

To remove openssl references from itacns_add_cert and itacns_check_and_add_keyset, I need more help/documentation/miracle...

If I understand correctly, in x506 cert there are two section (key usage and key extended usage) which are used to define public and private keys usage in itacns_check_and_add_keyset. KeyUsage can be read with sc_pkcs15_get_bitstring_extension, right? Using same function for extendedKeyUsage (changing OID) give me an error (maybe because it isn't a bitstream?)
I'm a little confused bc sc_pkcs15_get_bitstring_extension give me 0x1 for keyusage (instead of 0x80 using openssl x509 functions).

Maybe I'm totally wrong...

The changes needed to build without OpenSSL may not be needed. Many OpenSC card drivers require OpenSSL, so the only time OpenSC would be built without it would be for some special memory limited device and then only for a specific card. (For example a door lock device.)

There have been no requests that I know of to use the CNS card without OpenSSL.

What you have without it is a reasonable fix for your problem. Sorry if I mislead you. If you do want to continue with this, see http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html Table 24, "Mapping of X.509 key usage flags to Cryptoki attributes for public keys".
OpenSC uses the intermediate PKCS15 flags to generate the PKCS11 attributes.

You should not need extended Key Usage in the card driver. The calling application and server have the certificate. There is no equivalent PKCS11 attribute. See https://en.wikipedia.org/wiki/X.509

openssl x509 can be used to print a certificate. openssl asn1parse to show the ASN1 tags. pkcs15-tool can extract a certificate to a file or to stdout and piped into the openssl tools.

https://lapo.it/asn1js/ is also useful to look at asn1 especially fom a debug log.

Thankyou for all the info you gave me.
I think my knowledge in now so limited to achieve a good job (and should be related to another branch/PR).

What is the status of this PR? It looks generally fine for me. Is there something more that needs to be done here or can we merge it?

As far as I can see, @dengert 's comments were related to the code quality of the card driver. Maybe those comments should be mirgrated to a seperate issue... The actual bugfixing (support for 2048) seems to be handled in this PR, so it's ready to be merged, right?

It should be OK to merge. My only unaddressed comment was about building without OpenSSL. This could be a separate issue. I don't know if anyone actually does this, but we supported it in the past. Should have a test action to build without OpenSSL?

Should have a test action to build without OpenSSL?

Appveyor builds a "Light" version, which doesn't include any dependencies, including OpenSSL.