(solo per riassumere la mia risposta a questa domanda duplicata su SO e i suoi commenti ...)
È certamente una cattiva pratica, e può anche essere un importante problema legale.
Poiché sia l'utente che il tuo servizio tecnicamente hanno avuto accesso alla chiave privata, non è più possibile garantire chi fosse il firmatario effettivo verso terzi.
Do you know any javascript library that signs xml, pdf and office documents? This way, the private key would only be used on client-side.
Non fare crypto JavaScript . Non sarai in grado di dimostrare all'utente cosa fa il tuo codice (potrebbe ancora inviare la chiave). Per quanto ne so, parte del progetto WebCrypto stava cercando di risolvere alcuni di questi problemi (ad esempio lasciando che alcuni codici JS usassero la chiave privata memorizzata nel browser senza farla uscire), ma non è ancora pronta, e non risolve tutti i problemi (es dimostrando agli utenti che cosa stanno firmando con quella chiave privata).
E, naturalmente, lo show-stopper tecnico ...
La maggior parte dei meccanismi di smart card non ti consente di accedere alla chiave privata stessa (spesso in base alla progettazione), quindi in qualche modo dovresti in qualche modo interfacciare con l'API della firma per la scheda.
Quella API in realtà non ti darà la chiave privata, ti permetterà solo di usarla per firmare qualcosa, l'elaborazione viene effettuata sulla carta stessa. Pertanto, qualsiasi piano per inviare la chiave privata da qualche parte o avere un codice (che non utilizza questa API) non funzionerebbe.
Mentre il certificato sulle smartcard può essere utilizzato dal browser per l'autenticazione con certificato client, perché i browser sono implementati per supportare questo come parte della propria interfaccia utente (niente a che fare con qualsiasi pagina web che si possa fornire), non credo c'è qualcosa di ovvio che uno script nella tua pagina web acceda a questo. (Questo lascerebbe anche il problema di fidarsi di ciò che il tuo codice JS effettivamente segnala.)