Ringraziandovi per la condivisione, di seguito le riflessioni di Aruba.
Premesse e riferimenti:
-
Opinione di chi scrive è che non sussista una norma che richieda espressamente la revoca dei certificati di autenticazione CNS nel caso in cui la certificazione del microchip scada, nel corso del periodo di validità della carta; quello della certificazione del microprocessore è una previsione che deriverebbe solo dagli obblighi relativi alla predisposizione della smart card per la funzionalità di firma digitale, come chiarito anche nelle Linee guida per l’emissione e l’utilizzo della Carta Nazionale dei Servizi, Versione 3.0 del 15 maggio 2006.
-
I Mod. ATe sono anche Carte Nazionali dei Servizi e pensiamo non sia sempre possibile, per un servizio online, distinguere un certificato di autenticazione CNS a bordo di una ‘normale’ CNS da un certificato di autenticazione CNS a bordo di un Mod. ATe, né è prassi in questi processi online entrare nel merito del microchip, di cui non esistono liste pubbliche della loro certificazione SSCD/QSCD consultabili applicativamente né sempre esiste una modalità incontrovertibile e unica per individuare applicativamente il modello.
-
Lo standard normativo ETSI EN 319 411-1 suggerisce e non obbliga la revoca d’ufficio del certificato di FEQ qualora la certificazione SSCD/QSCD del dispositivo di firma risulti scaduta; è invece obbligatorio dichiarare sul CPS la politica applicata in questi casi, che in genere coincide con la revoca del certificato di firma, a meno che non sia possibile accertarsi della cancellazione fisica della chiave privata.
Commenti e suggerimenti:
In generare, seppur possa essere apprezzata l’intenzione dell’iniziativa, si intende far osservare che le presenti LLGG producono disomogeneità di gestione tra i Mod. ATe e le mere CNS e conseguentemente potenziali vuoti normativi.
In particolare, non è stato previsto che le normali CNS possano esplicitamente godere di tali deroghe in caso in cui la certificazione del dispositivo risulti scaduta.
A tal proposito, ci si chiede come un servizio online possa distinguere una CNS che non dovesse godere di una deroga (CNS o TS-CNS), da una CNS che dovesse invece godere di una deroga (Mod. ATe) a fronte del presente regolamento, potendosi probabilmente solo affidare alla possibilità che al Certificatore venga richiesto (da un Autorità o dall’Ente emettitore) di revocare il certificato di autenticazione CNS non soggetto a deroghe, seppur in assenza di espliciti obblighi normativi e di evidenze forti sulle possibili vulnerabilità dello strumento. Si consideri poi che questa circostanza ed interpretazione avrebbe impatti davvero importanti in ambiti estesi come quello del servizio TS-CNS.
Considerando poi le articolate disposizioni di cui al documento CNS – File System v.11 del 29 gennaio 2024 per consentire l’utilizzo di chiavi RSA a 2048 bit, a 3072 bit o superiori ed equivalenti chiavi crittografiche con curve ellittiche, si esprime generale preoccupazione che la presente regolamentazione possa ulteriormente indurre confusione sul sistema e sugli utilizzatori, anche con potenziali impatti sul mercato delle CNS e della firma locale con smart card. Sarebbe probabilmente suggeribile pensare a una disciplina unitaria e organica sul tema, quantomeno per i Mod. ATe e le CNS/TS-CNS, discussa preventivamente con i principali stakeholder e i QTSP.
Entrando comunque nel dettaglio,
Paragrafo 1 – a scanso di equivoci si suggerisce di specificare che i modelli ATe sono emessi utilizzando un microprocessore la cui conformità è attestata “da una certificazione in corso di validità emessa ai sensi” del Regolamento eIDAS.
Paragrafo 2 – Valutare attentamente se la postilla “la cui chiave privata sia a bordo del microprocessore” sia sufficientemente chiara per circoscrivere l’ambito di regolamentazione dell’eventuale obbligo di revoca. In ogni caso, qui la criticità principale che ravvediamo starebbe, come premesso, nel fatto che la previsione di poter continuare a utilizzare lo strumento fino alla propria scadenza, per finalità di identificazione e autenticazione, indirizzi il problema solo per le carte Mod. ATe senza preoccuparsi della sua reale applicabilità sul sistema. Inoltre, non è specificato se si intenda “identificazione elettronica” e rispetto a quale “livello di garanzia” (si vedano a tal proposito anche le previsioni di cui alle specifiche CNS – File System di AgID).
Paragrafo 3 – Si suggerisce che in caso di “incidente”, debba essere uno specifico Ente (es. ACN/OCSI) a decidere, e quindi comunicare e disporre dell’eventuale revoca dei certificati, siano essi di firma che di autenticazione. Si consideri che in caso di “sopravvenute vulnerabilità“ la revoca anticipata della certificazione del microprocessore potrebbe essere tempestiva e non sufficientemente ed adeguatamente preventivata. Potrebbe non essere quindi sempre possibile operare garantendo l’immediata revoca dei certificati digitali esattamente entro la revoca della certificazione e andrebbe chiarito che questo non comporta necessariamente una non conformità del Certificatore, se il piano di azione dovesse essere stato concordato con un’istituzione (es. ACN/AgID) e lo stesso certificatore dimostra di aver messo in campo tutte le azioni necessarie e opportune per una gestione della criticità in tempi rapidi (esempio entro 30 giorni dalla revoca della certificazione del dispositivo) e comunque in funzione del rischio reale.
Grazie dell’attenzione.