La PEC europea inizia a prendere corpo. REM, SERCQ, novità e accorgimenti

La recente notizia della qualificazione da parte dell’Agenzia per l’Italia Digitale del primo gestore di Posta Elettronica Certificata (PEC) che si è adeguato al nuovo standard europeo riaccende l’attenzione sulla PEC e la sua evoluzione in Servizio Elettronico di Recapito Certificato Qualificato (SERCQ), iniziata nel 2018.

Con questo post intendo dare un’idea del contesto complessivo nel quale si inserisce la revisione della PEC italiana, cosa sono le specifiche REM, quali sono gli impatti su chi attualmente usa la PEC e quali miglioramenti è lecito attendersi dalle novità introdotte^[1]Il post trae ispirazione anche da un post di Linkedin che ricondivide la notizia dell’iscrizione del primo gestore di PEC europea nel registro AgID.

Attenzione: il post non intende scendere nel dettaglio tecnico e giuridico della questione ma solo offrire qualche strumento (ragionato) per chi si occupa di trasformazione digitale. Qualche semplificazione è quindi inevitabile.

Il quadro della situazione

La PEC (Posta elettronica certificata) è uno strumento di recapito elettronico certificato tutto italiano che ha visto la luce a inizio millennio e sistematizzazione normativa nel 2005^[2]Decreto del Presidente della Repubblica 11 febbraio 2005, n. 68.

Il regolamento europeo eIDAS, che ha lo scopo di creare un quadro uniforme per garantire la fiducia nelle transazioni elettroniche all’interno del mercato unico europeo, detta regole di alto livello, tecnologicamente neutre, per definire i requisiti che un servizio di recapito elettronico deve avere per potervi riporre il giusto affidamento. In particolare, eIDAS definisce anche una categoria di servizi, detti SERCQ (Servizi Elettronici di Recapito Certificato Qualificato), che costituisce il livello massimo di affidabilità e prevede l’intervento obbligatorio di un “prestatore di servizi fiduciari qualificato”, cioè un soggetto al quale l’autorità pubblica trasferisce alcuni poteri tradizionalmente pubblici^[3]Niente di nuovo sotto il sole: in Occidente, già dal Medioevo, l’autorità pubblica ha investito di publica fides soggetti privati (i notai)..

L’ente europeo di normazione tecnica in ambito IT ETSI (European Telecommunications Standards Institute) ha elaborato le specifiche tecniche REM (Registered Electronic Mail)^[4]Titolo completo: EN 319 532-4 – V1.3.1 – Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail (REM) Services; Part 4: Interoperability profiles – la parte 4 … Continue reading, che realizzano, a livello tecnico, un SERCQ. Le specifiche sono basate sugli stessi protocolli di comunicazione della tradizionale e-mail (fra cui, per esempio, il protocollo SMTP) ai quali sono associati ulteriori protocolli e standard che garantiscono sicurezza e affidabilità del processo complessivo, per esempio per quanto riguardo identificazione e autenticazione dei proprietari della casella di posta.

A livello nazionale, l’Agenzia per l’Itala Digitale (che ha per l’Italia il ruolo di agenzia di vigilanza a norma dell’articolo 17 di eIDAS) ha avviato, su impulso del decreto legge n. 135 del 14 dicembre 2018, il percorso per trasformare la PEC italiana in PEC europea tramite il recepimento dello standard ETSI per la REM (Registered Electronic Mail) nell’ordinamento italiano. A partire dal 2018, quindi, l’AgiD ha lavorato, insieme ai gestori della PEC e altri soggetti istituzionali, al recepimento della specifiche REM elaborando il documento REM SERVICES Criteri di adozione standard ETSI Policy IT (in breve “REM-Policy-IT“)^[5]Come spiega il glossario in apertura del documento, si tratta, in definitiva, di un nome anglofono per le tradizionali “regole tecniche”. Per le regole REM, ogni dominio di … Continue reading, attualmente alla versione 2.0. Rispetto allo standard ETSI REM, che consente alcune scelte discrezionali, la policy italiana (IT) prevede alcune peculiarità^[6]Il gruppo di lavoro istituito da AgID ha “l’obiettivo di recepire gli standard ETSI e di trovare le soluzioni per implementare tutti i requisiti obbligatori degli standard (indicati col … Continue reading.

Novità italiana: i dati identificativi del mittente

Fra le novità italiane del recepimento dello standard tecnico REM (v. par. 4.3.4, lettera G.), il messaggio di testo inserito dal gestore nella busta di trasporto dà conto in modo evidente del nome del titolare della casella mittente e, anche se non come obbligo ma solo come raccomandazione, anche del suo codice fiscale (si veda l’esempio contenuto nel pacchetto di esempi allegato all’ultima revisione di REM-Policy-IT: REM_DispatchExt.RA01.eml).

Tradizionalmente, la PEC come conosciuta finora, presa da sola, fornisce solo garanzie certe rispetto a data e ora di invio e consegna del messaggio e di integrità del suo contenuto. Non fornisce, invece, garanzia diretta dell’identità del mittente. La provenienza del messaggio e dei suoi allegati (intesa come riconducibilità all’autore) è affidata ad altri strumenti, quali firme elettroniche applicate ai dati trasmessi, firme autografe digitalizzate e accompagnate da copie di documenti d’identità ecc..

Con le nuove regole, invece, chi riceve il messaggio ha un’informazione certa sul titolare della casella mittente e sul fatto che il contenuto del messaggio sia riferibile a questi.

Specifichiamo meglio, l’indicazione del nome e cognome (o ragione sociale) è da ritenersi del tutto attendibile, perché non è il mittente che scrive il suo nome in calce a un messaggio ma è proprio il gestore della casella del mittente che certifica il dato. Nello specifico:

• il gestore della PEC sa a chi è il titolare della casella perché le regole REM lo obbligano a identificarlo in maniera certa (per esempio tramite l’identità digitale SPID) prima di assegnargli la casella stessa;
• non solo, ancora le regole REM impongono un’autenticazione di tipo forte per chi (scrive e) invia il messaggio (per esempio il doppio fattore di autenticazione) in modo da escludere utilizzi abusivi da parte di soggetti diversi dal titolare della casella;
• l‘indicazione del mittente nel corpo del messaggio di trasporto (Dispatch message, in gergo REM) è quindi del tutto attendibile;
• chi riceve il messaggio, quindi, può essere certo della provenienza del messaggio ed estendere l’autorialità della comunicazione a tutti i documenti allegati.

In punto di diritto, le caratteristiche di sicurezza, integrità, immodificabilità e riconducibilità all’autore – indicate dall’articolo 20 del Codice dell’amministrazione digitale come criteri per valutare la capacità di un documento informatico di “soddisfare il requisito delle forma scritta” e avere efficacia probatoria di scrittura privata – sono garantite in pieno, anche se l’ordinamento prevede che sia sempre il giudice a valutare liberamente caso per caso.

Se si esige una validità giuridico-probatoria incontrovertibile, a parte qualche revisione dell’articolo 20 che tratti direttamente il caso di PEC adeguate alle specifiche REM che si può forse auspicare ma non pretendere, occorre, almeno in ambito pubblico, fare riferimento all‘articolo 65 del Codice dell’amministrazione digitale stesso, che – nella lezione vigente al momento della scrittura di questo post – stabilisce (comma 1, lettera c-bis)) che ha validità un’istanza o comunicazione trasmessa alla pubblica amministrazione dal domicilio digitale del dichiarante o istante. Ora, un indirizzo PEC o altro SERCQ è domicilio digitale di qualcuno solo se registrato formalmente in un indice pubblico (IndicePA, INI-PEC o INAD): serve, quindi, qualcosa in più rispetto alla mera indicazione certificata del titolare della casella^[7]Anche in questo caso una revisione della norma è auspicabile e nemmeno troppo pretenziosa: infatti, qualche versione precedente dell’articolo 65 indicava fra le condizioni in grado di … Continue reading.

Quest’ultima, tuttavia, consente di effettuare i controlli nei registri, soprattutto per quanto riguarda INAD. INAD, infatti, consente di verificare se un indirizzo PEC è domicilio digitale di qualcuno a una certa data solo se di quel “qualcuno” si fornisce anche il codice fiscale. A tal fine, specie se si vuole automatizzare la verifica, sarebbe utile avere il dato del codice fiscale non solo come obbligatorio ma anche come dato strutturato, incasellato magari nella “SubmissionAcceptance.xml” (che amplia il contenuto di quanto siamo abituati a vedere nel file daticert.xml che arriva nella busta di trasporto). Un passo alla volta, magari, ci arriviamo.

Le preoccupazioni di chi usa sistemi collegati a caselle PEC

L’esperienza personale, da cittadino, di chi è titolare di una casella PEC presso un gestore che ha avviato l’adeguamento europeo, mostra che a livello operativo le due azioni richieste all’utilizzatore finale sono:

• identificazione certa tramite identità digitale SPID (o simile);
• attivazione del secondo fattore di autenticazione per l’accesso alla webmail (per esempio password OTP^[8]Su cosa ci sia dietro le password OTP mi riprometto di pubblicare un post nel futuro prossimo. o notifica puch su smartphone) o alle app per dispositivi mobili.

Cosa succede quando la casella PEC non è gestita da una persona “umana” ma da una macchina, per esempio riguardo all’inserimento del codice OTP per il doppio fattore di autenticazione? Questa una delle preoccupazioni ricorrenti raccolta fra chi si occupa di gestione documentale nella pubblica amministrazione e si chiede come continuerà a realizzarsi il collegamento stabile fra sistema di gestione documentale (SGID) e casella PEC e se e quali adeguamenti è necessario predisporre.

Il doppio fattore di autenticazione

Il doppio fattore di autenticazione nella forma di inserimento di un OTP generato da una app proprietaria del gestore della casella o da una generica oppure la ripetizione del codice di sblocco del dispositivo mobile è qualcosa che funziona solo per accessi a una casella PEC eseguiti da una persona in carne ed ossa e non da un sistema automatizzato.

Come garantire un’autenticazione forte da parte di un sistema automatico, quale il sistema di gestione informatica dei documenti di una pubblica amministrazione ma anche un più comune client e-mail come Thunderbird o Outlook diffuso anche per uso privato, è questione che la REM-Policy-IT affronta esplicitamente al paragrafo 2.4.2.7 dell’allegato tecnico. In sintesi:

• il titolare della casella accede (con doppio fattore di autenticazione) al pannello di controllo del servizio messo a disposizione dal gestore e abilita l’accesso alla casella tramite i protocolli POP3, SMTP e IMAP utilizzati dai client e-mail;
• il titolare crea una password (detta Application password) che sarà valida esclusivamente per l’accesso alla casella tramite client;
• la Application password è soggetta a misure di sicurezza quali la necessità di cambiarla periodicamente (ogni sei mesi, in via indicativa).

L’autenticazione forte “che ci chiede l’Europa”, quindi, non va a minare il collegamento fra sistemi di gestione documentale e caselle PEC e non obbliga nemmeno gli affezionati dei software di gestione delle caselle e-mail a cambiare abitudini. A titolo informativo, le specifiche ETSI prevedono anche altre forme di autenticazione forte dei client, che però non trovano applicazione perché “non risultano ancora sufficientemente diffuse nei vari prodotti di mercato”.

Formato e sintassi dei dati di certificazione

Le specifiche REM prevedono le cosiddette “evidence” che sono i dati che i gestori aggiungono al messaggio originario quando lo elaborano (per esempio il file daticert.xml) o che vi associano in seguito (nel caso delle ricevute). Nel mondo PEC questi dati hanno formato e struttura definiti dalle regole tecniche della PEC. Il passaggio alle regole REM, pur restando stabile la predilezione per l’XML, prevede sintassi diverse e, solitamente, un maggiore dettaglio.

Ora, fin tanto che l’interazione con il servizio di recapito è fatta da un utente umano, anche se i messaggi di testo libero sono un po’ diversi, non cambia un granché. Cambia, invece, se i messaggi (busta di trasporto e ricevute) sono processati da una macchina. Occorre istruire il software che gestisce la casella a interpretare correttamente i dati nella loro nuova forma. Niente di inarrivabile, anche perché il gruppo di lavoro della REM-Policy-IT ha dichiaratamente operato con “l’obiettivo di facilitare la transizione al nuovo servizio da parte degli utenti di piattaforme nazionali e servizi attualmente basati sulla PEC“^[9]Paragrafo 3.2, verso la fine..

Adeguamenti del sistema di gestione documentale delle pubbliche amministrazioni

Se un sistema di gestione informatica dei documenti (o altro sistema) è già collegato già con le caselle PEC continuerà a essere collegato con la casella PEC europea adeguata alle specifiche REM, perché i protocolli di comunicazione sono fondamentalmente gli stessi.

Poiché occorre creare e cambiare periodicamente una password ad hoc per l’accesso alla casella da parte del SGID (che opera come client e-mail), è necessario che il fornitore del SGID metta a disposizione la funzione (di facile uso) per aggiornare la password e che qualcuno stia dietro alla scadenza della password, alla generazione di una nuova password e al suo inserimento nel sistema (operazione che poi avviene già ora se la PEC è attiva presso alcuni gestori).

In realtà^[10]Ringrazio espressamente per avermi segnalato il riferimento puntuale Marco Mangiulli, che fa parte del gruppo di lavoro della REM-Policy-IT., la REM-Policy-IT prevede (paragrafo 2.4.2.13 dell’allegato tecnico – Policy generali di autenticazione) anche metodi più sofisticati ed eleganti per gestire l’autenticazione M2M (Machine-to-Machine) da parte di un sistema informatico struttturato come può essere il sistema di gestione documentale di un ente. I dettagli tecnici fanno riferimento al framework di autenticazione OAuth 2.0 e spostano l’integrazione dell’applicativo con la casella dai tradizionali protocolli POP3, SMTP e IMAP ad API di tipo REST^[11]E’ nominata anche una variante che poggia su protocollo XOAUTH2 e accesso tramite, POP3, SMTP e IMAP che, però, “deve essere ovviamente supportato dal servizio di messaging sul quale è … Continue reading. Al di là dei dettagli tecnico-informatici però, viene da chiedersi se i sistemi di gestione documentale della pubblica amministrazione abbiano effettivamente quel livello di maturità che serve per implementare metodi più moderni per l’autenticazione. Il passaggio alla nuova PEC, allora, potrebbe essere l’occasione per migliorare i software in uso anche in quegli aspetti meno vistosi e visibili che, tuttavia, abilitano funzioni diversamente non realizzabili. Del resto una gestione più versatile dell’autenticazione è utile anche per gestire gli accessi degli utenti stessi del software^[12]Pensiamo all’abilitazione di meccanismi di single-sign-on, magari collegati alle identità digitali. Oppure meglio continuare a essere sommersi da coppie di credenziali ed eventuali OTP per … Continue reading.

Il SGID dovrà invece adeguare sicuramente (compito del fornitore) la logica di processamento dei messaggi, perché cambiano i formati e la sintassi dei file con dati strutturati che costituiscono la certificazione del messaggio. Oggi un SGID è in grado di intercettare nella casella PEC le ricevute di accettazione e consegna e, invece che proporle all’operatore per la registrazione (o per lo scarto) le elabora automaticamente e le associa, come da regole tecniche del protocollo informatico^[13]Dpcm 3 dicembre 2013, «Regole tecniche per il protocollo informatico»,articolo 18, comma 1 (ancora vigente)., alla registrazione in partenza. Il meccanismo automatico funziona perché le ricevute presentano le informazioni che veicolano secondo una struttura standard che, come detto poco sopra, cambia con le specifiche REM.

Oltre le specifiche tecniche

Si deve però andare oltre gli adeguamenti meramente tecnici alle nuove specifiche tecniche e pretendere di cogliere i vantaggi che l’evoluzione della PEC ci offre, a partire dall’indicazione certificata dell’identità del mittente, richiamata in apertura.

Arrivando subito all’operatività un sistema informatico che gestisce una casella PEC (europea) deve consentire:

• di recuperare il codice fiscale del mittente dal messaggio certificato;
• verificare se, al momento dell’invio, l’indirizzo mittente è domicilio digitale generale associato al codice fiscale in un registro pubblico (INAD o INI-PEC, ma anche IndicePA);
• segnalare chiaramente all’operatore l’esito della verifica e annotarlo nei dati di registrazione del messaggio.

Il motivo, già spiegato in precedenza con riferimento all’articolo 65 del Codice dell’amministrazione digitale, dovrebbe essere chiaro. Ma, Codice dell’amministrazione a parte, ripeterlo non guasta:

• ricevo una PEC che, per sua natura tecnica, garantisce l’integrità del contenuto (cioè che corrisponde a quanto inviato);
• il gestore della PEC, che è un soggetto autorizzato dallo Stato e dotato di poteri di certificazione, mi dice chi è il titolare della casella PEC;
• le regole REM mi garantiscono che l’utente che ha inviato il messaggio è stato accuratamente identificato prima che inviasse il messaggio ed è quindi, oltre ogni ragionevole dubbio, il mittente reale del messaggio^[14]E se anche non lo è, lo è, perché vuol dire che ha accettato che qualcun altro entrasse nella casella al suo posto.
• quindi il gestore sta “sigillando” con la sua autorevolezza un messaggio unito alla certificazione dell’identità del suo mittente;
• in più, se ho anche un riscontro su un registro pubblico che quella casella PEC è il domicilio digitale del suo titolare, non c’è più davvero alcun dubbio: il titolare ha ulteriormente dichiarato che quella casella PEC ha pieno effetto per le comunicazioni a valore legale che lo riguardano.

Preliminarmente – va detto – occorre che i gestori PEC concordino di indicare sempre e comunque il codice fiscale del mittente, anche se la REM-Policy-IT prevede il dato solo come raccomandato. Se anche passato come testo libero (ma secondo uno schema prestabilito), il recupero automatico è possibile. In generale, comunque, è doveroso a pretendere dai software in uso funzioni che valorizzino le innovazioni, altrimenti queste rimangono delle incompiute.

Cosa manca(va) alla PEC

Chiudo con un richiamo dal gusto quasi scolastico sul motivo per cui è iniziato il percorso di “aggiornamento” della posta elettronica certificata nostrana, partendo dal regolamento eIDAS.

La dimensione e l’uso transfrontaliero non possono esistere se non nella cornice di una regolamentazione unica europea che si è iniziata a delineare con il regolamento eIDAS. L’evoluzione della PEC è quindi inevitabile, visto che pre-esiste a eIDAS grazie a norme e regole tecniche nazionali (così nazionali che, addirittura, i tag degli schemi XML parlano italiano)..

A parte questo però, anche le caratteristiche tecniche della PEC italiana presentano dei limiti che non le consentono di aspirare al livello più alto previsto da eIDAS per i servizi di recapito senza qualche modifica.

eiDAS definisce un Servizio Elettronico di Recapito Certificato (SERC), all’articolo 3 definizione n. 36), come “un servizio che consente la trasmissione di dati fra terzi per via elettronica e fornisce prove relative al trattamento dei dati trasmessi, fra cui prove dell’avvenuto invio e dell’avvenuta ricezione dei dati, e protegge i dati trasmessi dal rischio di perdita, furto, danni o di modifiche non autorizzate”. Fino a qui la PEC, dal punto di vista tecnico, soddisfa i requisiti.

Come per altri servizi fiduciari, eIDAS definisce anche una versione qualificata, caratterizzata dall’intervento di un soggetto qualificato (QTSP – Qualified Trust Service Provider, per dirla in inglese), i SERCQ, appunto, che in più rispetto al SERC soddisfano i requisiti indicati all’articolo 44:

• sono forniti da uno o più prestatori di servizi fiduciari qualificati;
• garantiscono con un elevato livello di sicurezza l’identificazione del mittente;
• garantiscono l’identificazione del destinatario prima della trasmissione^[15]In inglese è scritto “delivery”, che rende un po’ meglio l’idea. Il destinatario è identificato prima che il suo gestore gli depositi (consegni) i dati nella casella, non … Continue reading dei dati;
• l’invio e la ricezione dei dati sono garantiti da una firma elettronica avanzata o da un sigillo elettronico avanzato di un prestatore di servizi fiduciari qualificato in modo da escludere la possibilità di modifiche non rilevabili dei dati;
• qualsiasi modifica ai dati necessaria al fine di inviarli o riceverli è chiaramente indicata al mittente e al destinatario dei dati stessi;
• la data e l’ora di invio e di ricezione e qualsiasi modifica dei dati sono indicate da una validazione temporale elettronica qualificata.

Dei sei requisiti, la PEC tradizionale è sicuramente carente rispetto all’identificazione con elevato livello di sicurezza di mittente e destinatario. Per questo sono state introdotte l’identificazione del titolare della casella tramite identità digitale (SPID o CIE) o metodi equivalentemente efficaci e l’autenticazione forte (doppio fattore o altro), di cui si è detto in precedenza.

Senz’altro le specifiche REM migliorano anche gli aspetti di sicurezza della trasmissione, forti di qualche anno di esperienza in più rispetto alle regole tecniche della PEC.

Vale infine la pena ricordare che eIDAS niente dice in merito al valore legale della trasmissione di dati tramite SERC o SERCQ, rimettendo la questione interamente – come giusto che sia – agli ordinamenti nazionali. L’unica disposizione riguarda, come per altri servizi, la non discriminazione (articolo 43): ai dati trasmessi tramite un SERC non si negano effetti giuridici e valore come prova “per il solo fatto della forma elettronica” e se

Cosa manca adesso

Il racconto fin qui e le azioni di AgID e co. si fermano agli aspetti tecnici e tecnologici. Perché la nuova PEC “europea” si sostituisca alle PEC attuale e assuma lo stesso valore legale manca, a occhio, la sistemazione della cornice normativa:

• sicuramente un atto di natura regolamentare (un decreto del Presidente del Consiglio dei ministri o un decreto ministeriale) che si sostituisca al dpr 68/2005 e al dm 2 novembre 2005 che disciplinano adesso il funzionamento della PEC e che approvi e renda cogenti le regole tecniche costituite dalla REM-Policy-IT;
• probabilmente una modifica dell’articolo 48 del Codice dell’amministrazione digitale che norma il valore legale della PEC e che stabilisce che la trasmissione tramite PEC equivale alla notificazione a mezzo posta: in realtà il comma 1 dello stesso articolo oltre all’esplicito riferimento alla PEC^[16]Esplicito nel senso che è richiamato con la solita perifrasi che si rifà alla norma di legge che istituisce lo strumento, in questo caso il dpr 68/2005., richiama anche “altre soluzioni tecnologiche individuate con le Linee guida” quindi, forse, approvate la REM-Policy-IT siamo a posto;
• la REM-Policy-IT fa riferimento anche all’articolo 29 del Codice dell’amministrazione digitale che si occupa però di qualificazione dei prestatori di servizi fiduciari: poiché un fornitore di SERCQ (nella sua declinazione di PEC adeguata alla REM-Policy-IT) è già stato qualificato da AgID tanto che compare nella Trusted list europea, pare che sia già tutto a posto.

Non resta che capire quando passeremo definitivamente alla nuova PEC, così da farci trovare pronti con gli strumenti debitamente adeguati.

Foto di dference da Pixabay