Di Santino Foti – Systems Analyst at InfoCert

Le comunicazioni digitali con la loro evoluzione e crescita smisurata in termini di volumi e numero di utenti coinvolti stanno ormai monopolizzando e caratterizzando gran parte del nostro tempo.

Lasciando da parte le comunicazioni legate alla vita privata (di cui si parlerà in un’altra occasione) e concentrandosi per un momento su quelle che hanno un carattere più formale, ad es. nel dialogo tra persone ed enti o tra enti stessi, vi è sicuramente stata una notevole evoluzione, anche se in misura più contenuta e modalità differente rispetto a quella delle comunicazioni private.

Questa differenza tra le due evoluzioni è certamente legata alle necessità che le due tipologie di comunicazione tendono a soddisfare. Questo è un concetto importante da tenere a mente e su cui si tornerà successivamente.

Non perderti i prossimi articoli, iscriviti alla newsletter!

Evoluzione e numeri delle comunicazioni digitali formali                  

Come sappiamo, in Italia, la domanda di digitalizzazione di questa tipologia di comunicazione formale è stata ricoperta dalla Posta Elettronica Certificata (PEC). I numeri che tale tecnologia gestisce oggi sono di tutto rispetto: i dati indicano ben oltre 12 milioni di utenti registrati e più di 2.5 miliardi di messaggi scambiati negli ultimi 12 mesi; entrambi i dati in forte crescita.

Tali numeri sono stati possibili grazie ad una serie di fattori oggettivi. Non ultimo la distribuzione dell’infrastruttura su 18 differenti fornitori di servizi[1] – che hanno potuto suddividere il carico di una così ampia mole di utenti e dati – favorita grazie anche al grande impulso e coordinamento che l’idea ha ricevuto dalle istituzioni.

Consideriamo che, nei servizi di questo tipo, il sostegno fornito da parte delle autorità competenti a livello regolatorio prima, e di supervisione, coordinamento e vigilanza dopo, non è casuale ma necessario, anzi fondamentale. Infatti, trattandosi di comunicazioni che devono dare “certezze” a chi ne fa uso, risulta assolutamente chiaro che una siffatta proprietà non la si riesce ad ottenere se non, in primo luogo, con delle “regole certe” (aspetto normativo, quindi).

Risulta altresì evidente che per arrivare ai numeri menzionati prima c’è tutto un percorso di anni, attraversato dall’incisiva collaborazione e dialogo tra istituzioni e fornitori del servizio. Coordinamento e vigilanza sui gestori del servizio da una parte, ma anche il viceversa: condivisione e risoluzione delle varie problematiche che sono emerse facendo fronte comune avvalendosi anche delle esperienze via via maturate nel campo e presso i fornitori di servizio[2].

Un sistema chiaro, regolamentato e vigilato ⏤ applicato ad infrastrutture tecnologiche che rispettino pienamente tali regole, ed in grado di sostenere la domanda di crescita emergente ⏤ fornisce una parte delle “certezze” di cui le comunicazioni digitali formali hanno bisogno: sicuramente quelle legate all’affidabilità, sostenibilità, pieno controllo nel lungo periodo del servizio stesso, a garanzia degli investimenti ed al riparo da perturbazioni estemporanee (di carattere emotivo ad es. o legate ad eventi o cause esterne).

Una seconda e non meno importante parte di “certezze” viene invece fuori da come si regolamenta un tale sevizio. Non avendo intenzione di affrontare la pura parte regolatoria (che è fuori ambito rispetto al presente testo), si vuole invece porre l’attenzione sulla parte di dispositivi tecnici che sono messi a disposizione di chi si occupa di produrre le regolamentazioni dei servizi: questi sono gli “standard” e tutte le documentazioni a corredo degli stessi.

L’importanza degli standard 

Gli standard sono in grado di dare tutte le garanzie che i servizi che vi aderiscono abbiano certe qualità.

Ma quali sono le qualità essenziali che un servizio di questo tipo deve avere?

Per rispondere a questa domanda ci vengono in aiuto i “principii” che sono riportati nei regolamenti. Nella fattispecie il regolamento eIDAS indica gli aspetti su cui porre l’attenzione. Senza entrare troppo nello specifico si menziona qui “l’interoperabilità” dei servizi tra i vari Paesi della comunità europea; e come seconda importante esigenza, la garanzia che tali sistemi abbiano sufficienti “protezioni” da attacchi malevoli.

Ad onor del vero, la Posta Elettronica Certificata ha già iniziato ad inserire nei propri flussi dei meccanismi di sicurezza con notevoli progressi in tale campo (alcuni significativi stanno per aggiungersi proprio in queste settimane, ed altri si aggiungeranno nel seguito), anticipando di fatto alcune delle misure di sicurezza previste nei principii emanati dal regolamento eIDAS.

Riguardo l’interoperabilità c’è in atto un percorso che vedrà evolvere la Posta Elettronica Certificata in un servizio rispondente agli standard disponibili per rispettare i principii espressi nel regolamento eIDAS (un po’ come è avvenuto, in più step, con la transizione della TV al digitale terrestre – DVB-T prima e DVB-T2 ancora in corso, o dagli storici modem 56KB all’ADSL prima, seguiti poi dalla fibra, citati giusto per fare alcuni esempi di transizione, anche se poco calzanti tecnicamente parlando, visto che rispondono ad altre esigenze).

Gli standard a cui si fa rifermento per la transizione della PEC sono quelli che vanno sotto il nome di REM (Registered Electronic Mail) pubblicati dall’ETSI (www.etsi.org), che forniscono tutte le garanzie in risposta ai principii presenti nel regolamento eIDAS, in particolare quindi all’interoperabilità e alla sicurezza.

Interoperabilità e suddivisione delle responsabilità

Ma per assolvere al requisito dell’”interoperabilità” delle comunicazioni digitali formali tra Stati Membri della comunità europea, cosa è fondamentale?

L’elemento più importante ⏤ che rappresenta un concetto generale e trasversale a questa tipologia di comunicazioni formali ⏤ è quello dell’”evidenza”: cioè la prova informatica e inconfutabile dell’avvenuta comunicazione, che l’utente può esibire in qualsiasi momento.

Questo concetto negli standard ETSI è rappresentato dalla cosiddetta ERDS evidence. Anche se probabilmente ovvio, si vuole qui sottolineare un particolare: si è detto che l’utente ha l’esigenza di certezze, e si è detto che  è fondamentale il “se” e il “come” è regolamentato un servizio per soddisfare tale esigenza (per questo si parla di servizi trusted o fiduciari). Ma c’è da aggiungere che il massimo delle certezze si raggiunge quando esiste qualcuno, per l’utente, che abbia la responsabilità per ognuno degli elementi costituenti tutti i livelli del servizio. Ecco l’ERDS evidence degli standard ETSI, quando adottata e, quindi, connessa e richiamata dalle norme, ricopre nettamente questo “se”, il “come” e le “responsabilità”.

Non solo, il “come” rappresentato nella ERDS evidence è una qualità così importante e così universale che ha delle potenzialità di lungo periodo uniche. Intanto è trasversale rispetto alle varie tipologie di standard relativi alle comunicazioni digitali formali (es. il cosiddetto eDelivery), indipendentemente dai protocolli utilizzati.

Ciò la rende “nativamente” interoperabile collocandola a rappresentare un fulcro sul quale poggiare, nel futuro, le evoluzioni dei servizi che attualmente la adottano. In altre parole possiamo vedere, usando la prospettiva opportuna, l’ERDS evidence come un primo elemento infrastrutturale di base nel lungo periodo.

REM ed ERDS evidence: backbone infrastrutturale     

Non si rileva al momento, nel mondo delle comunicazioni digitali formali, qualcosa che sia pienamente paragonabile all’ERDS evidence dello standard ETSI, ovvero qualcosa che copra tutte assieme le qualità e caratteristiche suddette in risposta alle “certezze” attese dall’utente.

Questo considerando il fatto che la ERDS evidence è definita ed è  integralmente e perfettamente integrata nell’intero set di standard ETSI dedicati all’eDelivery: ERDS (Electronic Registered Delivery Services) e REM (Registered Electronic Mail) Services. E si sottolinea anche che, il fatto che tali strumenti siano uno “standard” (c’è un organismo che, attraverso processi ben determinati, ha la responsabilità di definirli e mantenerli nel tempo) vuole anche dire che si può fare affidamento su di essi. In altre parole anche questo anello della catena, come tutti gli altri, fornisce una risposta “rispettabile” alle domande di certezza menzionate prima.  

La REM, per la sua prossimità tecnologica con la PEC è stata scelta per ospitare le attuali utenze della stessa, transitandone così il traffico verso un servizio sicuro ed interoperabile secondo i principii del regolamento eIDAS.

L’accoppiata REM + ERDS evidence (che è nativamente integrata nella REM) costituisce un secondo ed ulteriore livello infrastrutturale. In altre parole la REM si appresta a rappresentare una sorta di “backbone” interoperabile a livello europeo e ad altissima capacità (considerati già solo gli attuali numeri della PEC) sul quale transitano i messaggi utente e le ERDS evidence, e su cui poggiare gli attuali ed eventuali nuovi servizi di comunicazione digitale formale.

Ciò detto, non si aggiunge altro sul tema “evoluzioni” sul quale si potrà dedicare in seguito un apposito approfondimento attento e aperto a 360 gradi.

Fruizione del servizio: interfacce umane ed applicative         

Una volta fatta luce sull’infrastruttura in grado di veicolare (o in altri termini “trasmettere”) le comunicazioni digitali formali, un capitolo a parte è rappresentato dalle modalità di fruizione del servizio.

Le attuali comunicazioni digitali formali effettuate tramite PEC, la utilizzano come sistema “molti a molti”. Infatti, non c’è un flusso esclusivo da una sorgente unica informativa che invia verso una moltitudine di utenze (uno a molti). Non c’è neanche un flusso esclusivo con il viceversa e cioè una moltitudine di utenti che invia verso un solo soggetto. Chiunque sia registrato al servizio può potenzialmente inviare a chiunque.

Ma allora, conservando tutti i vantaggi che ha questa tipologia di servizio “aperto” e poggiato su un “backbone”, altri vantaggi vi si possono aggiungere attraverso opportune “interfacce utente” (o applicativi o app utente che dir si voglia). In altre parole un’ulteriore modernizzazione o semplicemente rimodulazione del servizio, adattandolo di volta in volta alle esigenze che possono emergere, può avvenire agendo su tali applicativi utente.

Questo disaccoppiamento consente un ulteriore vantaggio: una volta fatto il primo passo, standardizzati il backbone e le interfacce di comunicazione tra backbone e gli applicativi-utente, i tempi e le modalità con cui far evolvere gli stessi possono essere differenziati.

Ciò non è un beneficio da poco: basti pensare agli impatti (e quindi ai contraccolpi verso l’utenza o verso i sistemi stessi) che ogni passo evolutivo crea e che invece da qui in avanti potrebbero essere praticamente azzerati, o quantomeno fortemente mitigati e controllati. E tutto questo giovamento c’è proprio perché si vanno a rendere standard i punti di contatto essenziali tra le varie entità in gioco. È stata menzionata l’”evidenza” che diverrebbe standard, ma anche il backbone implementato con la REM diverrebbe un’infrastruttura strategica aderente ad uno standard (i cui moduli e le relative interfacce si poggiano a loro volta su standard internazionali), e così via – senza entrare eccessivamente in dettagli tecnici.

Giusto per fare un esempio, un backbone distribuito su un certo numero di Service Provider con interfacce standard e interoperabili (nel caso in esame la REM) può essere reso disponibile all’utenza utilizzando degli applicativi tra i più disparati: App per dispositivi mobili, App per PC desktop, applicativi legati a funzioni particolari quali protocollo, fatturazioni, etc., o anche applicativi dedicati per sistemi informativi automatici di enti di svariato tipo.

Ma non solo: essendo nel caso della REM l’interfaccia di utilizzo uno standard utilizzato da applicativi già presenti nei dispositivi utente (nella fattispecie i client della posta elettronica presenti nativamente in tutti i dispositivi mobili e PC di qualsiasi tipo) ne consegue che le possibilità di fruizione vengono a moltiplicarsi. E ciò lasciando libero l’utente di scegliere, per l’accesso ed uso del servizio, la piattaforma e il sistema operativo di riferimento che più gli aggrada senza richiedere che sia necessariamente installato del software ad hoc e specifico per l’uso del servizio.

Quello che emerge è uno sganciamento di un numero di funzionalità, in un certo modo autoconsistenti, ed ognuna con un proprio ed intrinseco grado di evoluzione, nel tempo, differente dall’altra. Alcune di queste (ad esempio quelle vicine all’utente) possono variare molto più rapidamente di altre, e quindi un’infrastruttura così modulare e standardizzata ne favorisce il cambiamento appena se ne manifesta l’esigenza o l’opportunità.

Stesso discorso dicasi per le pratiche relative alla sicurezza: queste devono essere senza dubbio indirizzate e referenziate, ma allo stesso tempo svincolate e manovrabili con una rapidità che non è quella degli standard e dei regolamenti del servizio base, ma piuttosto quella legata ad apposite prassi di sicurezza che seguono, per ovvie ragioni, dinamiche e tempestività proprie non sempre in sincronia con le altre.

Futuri approfondimenti     

Come accennato prima, un capitolo a parte, che si vedrà in un prossimo appuntamento, merita la questione delle evoluzioni successive di un sistema di questo tipo, che deve essere attento agli attuali limiti che esso stesso può incontrare, alle richieste di capacità crescenti che via via stanno emergendo ed il tutto rapportato alla reale domanda dell’utenza.

Inoltre, in questo compito, come accennato all’inizio del presente testo, risulta anche necessario valutare bene le necessità di questa tipologia di comunicazione che sono ben diverse dalle comunicazioni a carattere privato. Per cui un’assimilazione e sovrapposizione sommaria delle due tipologie di evoluzioni (quella dei mezzi ad uso privato e quello relativo alle comunicazioni formali) potrebbe avere degli effetti collaterali ed indesiderati da non sottovalutare.

Analogamente con analoga rilevanza, un ulteriore momento, con delle riflessioni specifiche, potrebbe essere dedicato in futuro esclusivamente al tema “sicurezza” delle comunicazioni digitali formali.

REM baseline e REM-Policy-IT        

Invece, in questo contesto, può tornare utile dire qualcosa in più sulla REM, la tecnologia scelta per ospitare l’attuale servizio PEC.

Alcuni dettagli di questo standard e l’approccio utilizzato per la scelta sono ritrovabili nel paragrafo 3 del documento “REM SERVICES – Criteri adozione standard ETSI – Policy-IT” pubblicato al seguente indirizzo:

Qui sono illustrati il metodo e i razionali che hanno fatto da guida al gruppo di lavoro tecnico istituito da AgID durante tutta l’attività di recepimento degli standard ETSI nella formulazione di quello che è previsto sia il servizio su cui transiterà l’attuale PEC.

Senza entrare troppo nei tecnicismi espressi in tale documento, si menzionano solo alcuni tasselli che fanno da fondamento all’intera idea.

REM baseline

Il primo è la cosiddetta REM baseline che costituisce il riferimento principale del suddetto documento, e che  rappresenta l’insieme di requisiti minimi da rispettare, in ambito dello standard ETSI REM, al fine del raggiungimento dell’interoperabilità a livello europeo (estendibile anche a livello internazionale).

Si consideri che la REM baseline definisce ed indirizza anche il concetto dell’identità dei soggetti interessati nell’ambito delle comunicazioni digitali; tema quello dell’identità ritenuto di fondamentale importanza a livello di sensibilità espresse nelle regolamentazioni europee e cruciale per l’utilizzo dei servizi fiduciari.

La sostanziale considerazione nella REM baseline del tema identità rafforza ulteriormente le “certezze” fornite all’utente, e di cui si è fatta menzione in precedenza, e valorizza ad un livello ineguagliabile le evidenze che accompagnano le comunicazioni digitali fornite attraverso questo servizio.

REM-Policy-IT

Il secondo è la REM-Policy-IT che è rappresentata dall’intero contenuto di tale documento e costituisce tutti i requisiti e dettagli tecnici che declinano e regolano la REM baseline all’interno e nell’ambito della realtà italiana e nel dialogo con altre realtà oltre frontiera.

Inoltre tale documento (dalla pagina 90 in poi) contiene un centinaio di pagine di un allegato tecnico in formato bilingue: italiano e inglese.

Qui si trovano tutti i dettagli più tecnici che illustrano come sono recepiti a livello italiano i requisiti e principii definiti dagli standard ETSI e dall’eIDAS regulation. In particolare i paragrafi 2.1 e 2.2 e la Table 1 (intorno alla 97a pagina del documento) forniscono una descrizione dettagliata ma contestualizzata di alcune nozioni molto importanti quali l’identificazionel’autenticazione e il concetto di registrazione al servizio (si sottolinea che l’eIDAS regulation parla di electronic registered delivery services, così come gli standard ETSI ERDS – Electronic Registered Delivery Services e REM – Registered Electronic Email services).

Infine, sempre nell’allegato tecnico, ci sono delle tabelle, figure ed esempi[3] che permettono un’interpretazione univoca degli standard nell’ambito della REM-Policy-IT con la conseguente riduzione, alla radice, di eventuali fraintendimenti che potrebbero essere frequenti, oltre che deleteri, in questo tipo di specifiche. Essendo tale allegato in formato bilingue, questa proprietà si ritrova estesa a tutti coloro che possono, in qualche forma, farvi riferimento.

Considerata tutta questa premessa, quello che si può concludere è che la REM rappresenta solo appena l’inizio di un processo che, sulla base delle esigenze che emergeranno, potrà portare a delle mutazioni[4]. Ciò con la consapevolezza di contenere, al proprio interno, delle componenti di base che si conserveranno e molti dei punti di raccordo, necessari alle evoluzioni o a nuove opportunità, già presenti o concettualmente predisposti nei razionali che costituiscono l’intero set di standard ETSI dedicato agli electronic registered delivery services.

Autore:

Santino Foti

Santino Foti

Systems Analyst at InfoCert


Documenti e News collegati al presente articolo

Il documento ufficiale relativo alla REM-Policy-IT menzionato nel testo sopra può essere recuperato al sito dell’AgID ai seguenti indirizzi:

Proprio in queste settimane si è concluso un importante evento denominato ETSI Plugtests event con l’obiettivo di mettere concretamente alla prova i sistemi REM live messi a disposizione dei partecipanti per testarne l’interoperabilità. Altre informazioni possono essere recuperate ai seguenti indirizzi:

Agid ha dato ampio risalto a questo evento al seguente indirizzo:


[1] Il tema della distribuzione di servizi “core” per la vita della società su una molteplicità di fornitori ha tutta una serie di risvolti che sono “lampanti”. Però, considerato l’ambito del presente testo, questo tema non viene approfondito oltre qui, per ovvie ragioni.

[2] Aspetto fondamentale questo, che è stato rafforzato, reso sinergico e strutturale nell’ultimo periodo affrontando le tematiche relative alla sicurezza dell’attuale sistema e la transizione verso il nuovo servizio interoperabile a livello europeo.

[3] Un intero set di esempi completamente funzionanti e dettagliati delle varie casistiche è fornito assieme all’allegato tecnico come ulteriore strumento di esemplificazione ed interpretazione di tutte le principali modalità in cui possono essere declinati i messaggi, le evidenze, i certificati digitali etc..

[4] Un po’ come è avvenuto, per step, negli esempi fatti prima in altri campi quali la TV o la connettività ad internet.